3G Umts Utran

Lucent UMTS Field Guide Volume II Feature Parameters and Best Practices
Network Operations Document NetOps-ND-00167
Rev. 1.3 06/07/06
Overview
The Lucent UMTS Field Guide Volume II describes the UTRAN functionalities, features, and related parameter settings associated with the UTRAN P1-Lite release (2005 and 2006 launch release). Feature parameter setting recommendations and best practices are presented which provide the best performance for an UMTS network (based upon FOA results and additional third-party test results). This document also describes the interaction between the existing GSM network and the overlaid UMTS network. This Field Guide is broken into 10 sections. Section 1 is introduction of this document. Section 2 lists all new features, functions and parameters when this document is updated in the event of new system software releases. Certain key KPIs related to these new features are also briefly covered in this chapter. Section 3 contains UE categories, RF terminologies and link budgets basics. Section 4 includes detailed description of all key features/functions, as well as engineering guidelines on related parameters of each feature/function. Section 5 introduces documentation for OSS implementation. Section 6 is a reference for utilizing OCNS. This will be especially helpful for engineers responsible for assisting with CA and FA. Section 7 contains the tables for all parameters explained in this document for handy reference. Cingular approved best practical values for these parameters (Cingular Recommended) are also listed and explained if necessary. Section 8 provides links and brief explanation of important test results from related projects (such like FOA, SOA) that contributed to the development of this volume II field guide. Section 9 provides a link to various Implementation Guides developed by CTO that may be of interest to the intended audience. Section 10 provides references used to create this document and an Index for content searches (to be added later, for now the PDF search feature should be used).
IMPORTANT: This document is the result of an ongoing collaborative effort between Cingular Market, Regional, National and Lucent staff and management. It will continue to be updated with the latest findings in the areas of optimization and vendor improvement through the use of commissioned studies and successive vendor software and hardware updates.
NetOps-xxxxxND-00167 Rev. 1.3 06/07/06
CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions
Page 1 of 248 (c) 2006 Cingular Wireless
Network Operations
Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite
Contents
1. About This Document..................................................................................................................... 12 1.1 Purpose ..................................................................................................................................... 12 1.2 Scope ........................................................................................................................................ 12 1.3 Audience ................................................................................................................................... 12 1.4 Related Documentation............................................................................................................. 12 1.5 Acronyms and Terms ................................................................................................................ 13 1.6 Trademarks ............................................................................................................................... 13 1.7 Conventions .............................................................................................................................. 14 1.8 Contacts .................................................................................................................................... 14 2. New Feature and New or Modified Parameter Lists ...................................................................... 15 2.1 New Feature Lists ..................................................................................................................... 15 2.2 Parameters................................................................................................................................ 15 2.3 KPI Introduction (NEW)............................................................................................................. 15 3. UMTS RF Design Fundamentals ................................................................................................... 16 3.1 UE Capabilities.......................................................................................................................... 16 3.1.1 UTRAN Frequency Bands ................................................................................................ 16 3.1.2 Channel Numbering Scheme............................................................................................ 16 3.1.3 UARFCN ........................................................................................................................... 17 3.2 UE Transmit power ................................................................................................................... 18 3.2.1 UE maximum output power .............................................................................................. 18 3.3 UE Reference Sensitivity Level................................................................................................. 18 3.4 UE Categories........................................................................................................................... 18 3.5 UMTS RF Measurement ........................................................................................................... 19 3.5.1 RSSI.................................................................................................................................. 19 3.5.2 CPICH RSCP.................................................................................................................... 19 3.5.3 Eb/N0 and Orthogonality, ............................................................................................... 20 3.5.4 Ec/I0 ................................................................................................................................... 20 3.5.5 SIR .................................................................................................................................... 21 3.5.6 Transmitted Carrier Power (TCP) ..................................................................................... 21 3.5.7 Transmitted code power ................................................................................................... 22 3.5.8 Transport channel BER .................................................................................................... 22 3.5.9 Physical channel BER ...................................................................................................... 22 3.5.10 BLER................................................................................................................................. 22 3.5.11 UE transmitted power ....................................................................................................... 22
Network Operations
3.6 UMTS Link Budget .................................................................................................................... 22 4. UTRAN Processes, Procedures & Recommended Parameter Settings ....................................... 25 4.1 Idle Mode Behavior ................................................................................................................... 26 4.1.1 System Acquisition ........................................................................................................... 26 4.1.1.1 4.1.1.2 UMTS Cell Search Procedure........................................................................... 27 Planning for Good Network Acquisition Performance....................................... 30
4.1.2 PLMN Selection ................................................................................................................ 31 4.1.3 Cell Selection & Reselection............................................................................................. 31 4.1.3.1 4.1.3.2 4.1.3.3 4.1.3.4 4.1.4.1 4.1.4.2 4.1.4.3 4.1.4.4 System Information Broadcast (SIB) Parameters for Cell Selection and Reselection ....................................................................................................... 32 Cell Selection (i.e. Camping on a Suitable Cell) ............................................... 34 Location Area / Routing Area Update ............................................................... 36 Cell Reselection ................................................................................................ 37 Discontinuous Reception for Paging................................................................. 46 Paging Channel Selection................................................................................. 47 Paging Procedures............................................................................................ 48 Paging Parameters in Idle Mode....................................................................... 48
4.1.4 Paging in Idle Mode .......................................................................................................... 46
4.2 Random Access and Call Establishment .................................................................................. 51 4.2.1 RRC States ....................................................................................................................... 51 4.2.2 RACH Access Procedure ................................................................................................. 53 4.2.2.1 4.2.2.2 4.2.2.3 4.2.2.4 4.2.2.5 4.2.2.6 4.2.2.7 4.2.3.1 4.2.3.2 Phase 1: RACH Preamble Part........................................................................ 54 Phase 2: Power Ramping Cycle ...................................................................... 58 Phase 3: RACH Message Part ........................................................................ 65 RACH Overload Control.................................................................................... 71 RACH Overload Control Parameter Settings.................................................... 72 Retransmission of the RACH Message Part..................................................... 73 Access-related Performance Measurements.................................................... 77 Circuit-Switched (CS) Mobile Origination/Termination ..................................... 78 Packet-Switched (PS) Mobile Origination/Termination..................................... 92
4.2.3 Call Establishment ............................................................................................................ 78
4.3 Mobility and Connection Management...................................................................................... 97 4.3.1 Load Control ..................................................................................................................... 97 4.3.1.1 4.3.1.2 Cingular Strategy .............................................................................................. 97 Overview ........................................................................................................... 97
Network Operations
4.3.1.3 4.3.1.4 4.3.1.5 4.3.1.6 4.3.1.7 4.3.1.8 4.3.1.9 4.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4 4.3.2.5 4.3.2.6 4.3.2.7 4.3.2.8 4.3.2.9
Load Estimation ................................................................................................ 98 Call Admission Control (CAC)......................................................................... 102 Congestion Control (CongC)........................................................................... 103 Dynamic Bearer Control (DBC)....................................................................... 104 RACH Overload Control.................................................................................. 110 Aggregate Overload Control ........................................................................... 111 Engineering Guidelines for Load Control related parameters......................... 111 Cingular Strategy ............................................................................................ 134 Overview ......................................................................................................... 134 DPCCH and DPDCH Overview....................................................................... 135 Open Loop Power Control............................................................................... 136 UL Open Loop Power Control ......................................................................... 137 DL Open Loop Power Control (DL DPCH Initial Tx Power)............................ 138 DL Closed Loop Power Control ...................................................................... 140 UL Closed Loop Power Control ...................................................................... 142 DL Power Balancing........................................................................................ 146
4.3.2 Power Control ................................................................................................................. 134
4.3.2.10 DL Common Channel Power Setting .............................................................. 148 4.3.2.11 Engineering Guideline for IRAT related parameters....................................... 151 4.3.3 Soft/Softer Handovers .................................................................................................... 171 4.3.3.1 4.3.3.2 4.3.3.3 4.3.3.4 4.3.3.5 4.3.3.6 4.3.4.1 4.3.4.2 4.3.4.3 4.3.4.4 4.3.4.5 4.3.4.6 4.3.4.7 4.3.4.8 Cingular Strategy ............................................................................................ 171 Overview ......................................................................................................... 171 Measurement Control and Reporting.............................................................. 173 SHO Algorithm ................................................................................................ 176 NLSA (Neighbor List Selection Algorithm) ...................................................... 178 Engineering Guidelines ................................................................................... 179 Cingular Strategy ............................................................................................ 188 Overview ......................................................................................................... 188 NodeB Capabilities and Configuration ............................................................ 194 Code and Power Allocation............................................................................. 196 Radio Resource Management ........................................................................ 197 State Transition with HSDPA .......................................................................... 202 Mobility ............................................................................................................ 204 Engineering Guidelines for HSDPA Related UTRAN Parameters.................. 208
4.3.4 HSDPA............................................................................................................................ 188
Network Operations
4.3.5 Inter-Technology Handovers (IRAT)............................................................................... 222 4.3.5.1 4.3.5.2 4.3.5.3 4.3.5.4 4.3.5.5 5. 6. 7. Cingular Strategy ............................................................................................ 222 Overview ......................................................................................................... 222 Basic Algorithm ............................................................................................... 223 Engineering Guideline for IRAT related parameters....................................... 230 2G to 3G HO ................................................................................................... 241
OSS Implementation Guide ......................................................................................................... 242 OCNS ........................................................................................................................................... 242 UMTS Recommended Parameters.............................................................................................. 243 7.1 Parameters to be Used for Launch and Moderately Loaded Clusters.................................... 243 7.2 Parameters to be Used for Acceptance Testing and High Capacity Clusters ........................ 243
8.
Test Results ................................................................................................................................. 244 8.1 FOA Test Results.................................................................................................................... 244 8.1.1 Executive Summary (FOA) ............................................................................................. 244 8.1.2 Link to Results (FOA) ..................................................................................................... 244 8.2 Parameter Field Trial Results.................................................................................................. 244 8.2.1 Executive Summary (Parameter Field Trial)................................................................... 244 8.2.2 Link to Results (Parameter Field Trials) ......................................................................... 244
9.
Implementation Guides ................................................................................................................ 245 10.1 Reference................................................................................................................................ 245 10.2 Index........................................................................................................................................ 246
10. Reference List and Index ............................................................................................................. 245
11. Appendix ...................................................................................................................................... 247 11.1 Appendix A Compressed Mode Description .......................................................................... 247
Figures
Figure 1: UMTS Link Budget Considerations and Interactions............................................................. 23 Figure 2: Overview of Possible State Transitions ................................................................................. 25 Figure 3: UMTS DL Frame Structure .................................................................................................... 26 Figure 4: 256-chip Sequence Correlation ............................................................................................. 28 Figure 5: Cell Search Stage 1 Slot Synchronization.......................................................................... 28 Figure 6: Cell Search Stage 2 - Frame Synchronization ...................................................................... 29 Figure 7: Cell Search Stage 3 - Scrambling Code Identification........................................................... 30 Figure 8: Acquisition Time versus CPICH Power Allocation................................................................. 31 Figure 9: Cell Selection/Reselection Process ....................................................................................... 32 Figure 10: System Information Block (SIB) Mapping ............................................................................ 33
Network Operations
Figure 11: Cell Reselection Example.................................................................................................... 40 Figure 12: Search Thresholds............................................................................................................... 44 Figure 13: Structure of Paging Indicator Channel (PICH)..................................................................... 47 Figure 14: Timing Relation Between PICH frame and associated S-CCPCH frame............................ 48 Figure 15: PICH Indicator Probability of Misdetection .......................................................................... 50 Figure 16: PICH Required Offset (Np=18) ............................................................................................ 50 Figure 17: UE Modes and RRC States in Connected Mode................................................................. 51 Figure 18: RACH Access Slot Format .................................................................................................. 53 Figure 19: RACH Preamble Part, Power Ramping Cycle, and RACH Message Part ........................... 54 Figure 20: Relationship Between Sub-Channel Number and Access Slot ........................................... 56 Figure 21: Power Ramping Cycle Illustration........................................................................................ 59 Figure 22: Timing Relation for aICHTransmissionTiming =0 ................................................................. 60 Figure 23: Timing Relation for aICHTransmissionTiming = 1 ............................................................... 60 Figure 24: Successful and Unsuccessful RACH Procedures ................................................................ 61 Figure 25: Flow Chart for RACH Procedures........................................................................................ 62 Figure 26: Parameter Settings for Phase 2 Power Ramping Cycle...................................................... 63 Figure 27: Parameter Relationship for powerRampStep & maxRetranPreamble ................................. 64 Figure 28: RACH Message Part for 10 ms Frame Length.................................................................... 66 Figure 29: TFI Illustration ...................................................................................................................... 67 Figure 30: RACH Message Part Power Settings .................................................................................. 68 Figure 31: Spreading of the RACH Message Part ................................................................................ 69 Figure 32: Basic RRC Connection Establishment Procedure (Successful).......................................... 74 Figure 33: Basic Cell/URA Update Procedure (Successful) ................................................................. 75 Figure 34: Guard Times for RACH Message Part ................................................................................ 76 Figure 35: t300 Parameter Study from Seattle-Tacoma ....................................................................... 76 Figure 36: Example of RRC Connection Request Parameters (taken from TEMS) ............................. 80 Figure 37: Example of RRC Connection Setup Messaging (taken from TEMS) .................................. 81 Figure 38: Examples of RRC Connection Setup Complete Messages ................................................ 82 Figure 39: Illustration of RRC Connection Setup Process (including RACH procedures).................... 83 Figure 40: Illustration of Service Request/Iu Connection Setup Process ............................................. 83 Figure 41: Illustration of Authentication and Security Process ............................................................. 85 Figure 42: Security Mode Command Message (taken from TEMS) ..................................................... 86 Figure 43: Illustration of Call Progress Information Process................................................................. 87 Figure 44: Illustration of Radio Link and Radio Access Bearer (RAB) Configuration ........................... 91 Figure 45: Call Connection - The Conversation Begins........................................................................ 92 Figure 46: UMTS Attach Procedure...................................................................................................... 94 Figure 47: PDP Context Activation sample message ........................................................................... 95 Figure 48: PDP Context Activation Procedure...................................................................................... 96 Figure 49 Measurement Reports ......................................................................................................... 101 Figure 50 Admission Control flow chart .............................................................................................. 103 Figure 51 Congestion Control flow chart.............................................................................................. 104 Figure 52 Dynamic Bearer Control flow chart ..................................................................................... 105
Network Operations
Figure 53 State Transition.................................................................................................................... 106 Figure 54 State Transition detailed diagram with parameter names .................................................. 107 Figure 55 DL Data Rate Increase ........................................................................................................ 109 Figure 56 DL data rate decrease ......................................................................................................... 110 Figure 57: Power Control Illustration................................................................................................... 134 Figure 58 UL DPCH (DPCCH and DPDCH) ........................................................................................ 136 Figure 59 DL DPCH (DPDCH+DPCCH) .............................................................................................. 136 Figure 60 Use Open Loop PC for initial power of DL/UL DPCCH ....................................................... 137 Figure 61 UL PC information in DL CCCH........................................................................................... 138 Figure 62 Power Offset between DL DPDCH and DL DPCCH ........................................................... 139 Figure 63 operation sequence in DL inner loop PC ............................................................................. 141 Figure 64 inner loop power control in UL ............................................................................................. 143 Figure 65 UL inner power control......................................................................................................... 143 Figure 66 Power Drifting ...................................................................................................................... 146 Figure 67 Power Balancing .................................................................................................................. 148 Figure 68 S- CCPCH structure and the power offset in S-CCPCH ..................................................... 149 Figure 69 MEHO Process .................................................................................................................... 172 Figure 70 structure of system Information block type 11 ..................................................................... 173 Figure 71 contents in Measurement Control........................................................................................ 174 Figure 72 triggering of 1A, 1B and 1C events...................................................................................... 177 Figure 73 HSDPA UTRAN Architecture............................................................................................... 189 Figure 74 HSDPA transmission principle............................................................................................. 190 Figure 75 HARQ Process..................................................................................................................... 191 Figure 76 Soft combining with multiple HARQ processors .................................................................. 191 Figure 77 UMTS Channels in HSDPA ................................................................................................. 192 Figure 78 Service Combinations for HSDPA ....................................................................................... 193 Figure 79 CED configuration with UCU II and HSDPA....................................................................... 195 Figure 80. 03.01 HSDPA Power allocation .......................................................................................... 197 Figure 81. CQI/ACK/NACK report repetition........................................................................................ 199 Figure 82 Mac-hs functions in UE...................................................................................................... 201 Figure 83 HSDSCH DCH transition procedure .............................................................................. 204 Figure 84 HSDPA Serving Cell Change ............................................................................................. 205 Figure 85 HSDPA Mobility Scenario 1 ................................................................................................ 207 Figure 86 Mobility Scenario 2............................................................................................................. 208 Figure 87. Inter System HO ................................................................................................................. 225 Figure 88. parameters involved in IRAT HO ....................................................................................... 226 Figure 89. example of e2d/e2f parameters in MC message................................................................ 227 Figure 90. event 2D triggering.............................................................................................................. 228 Figure 91. event 2F triggering .............................................................................................................. 229 Figure 92. event 3A triggering.............................................................................................................. 230
Network Operations
Tables
Table 1: UTRAN Frequency Bands ...................................................................................................... 16 Table 2: UARFCN Definition (General)................................................................................................. 17 Table 3: UARFCN Definition (Additional Channels).............................................................................. 17 Table 4: UTRA Absolute Radio Frequency Channel Number .............................................................. 18 Table 5: UE Power Classes .................................................................................................................. 18 Table 6: Reference sensitivity ............................................................................................................... 18 Table 7: UE Categories......................................................................................................................... 19 Table 8: Sample Link Budget ................................................................................................................ 24 Table 9: CPICH and SCH Power Settings for Cell Search ................................................................... 27 Table 10: Cell Selection Parameter Recommendations ....................................................................... 35 Table 11: Time Requirements and DRX Cycle Lengths ....................................................................... 38 Table 12: Cell Reselection Recommended Parameters....................................................................... 43 Table 13: Paging Parameters ............................................................................................................... 49 Table 14: Parameter Settings for Phase 1 RACH Preamble Part ........................................................ 57 Table 15: SF and TFCI Used for Different TTI/TFI Combinations ......................................................... 67 Table 16: Quantization of Gain Factors c and d .................................................................................. 69 Table 17: Phase 3 RACH Message Part Parameter Settings .............................................................. 70 Table 18: RACH Overload Control Parameters .................................................................................... 73 Table 19: UMTS QoS Classes .............................................................................................................. 89 Table 20: UMTS QoS Class vs. Error Tolerance Matrix ........................................................................ 89 Table 21: Lucent Radio Access Bearers (RABs) .................................................................................. 90 Table 22 Load Measurement Related Parameters ............................................................................. 100 Table 23 Supported RAB in 03.01 ....................................................................................................... 108 Table 24 Function of Power Control .................................................................................................... 135 Table 25 NodeB Capacity Table .......................................................................................................... 194 Table 26 HS-DPCCH power offset .................................................................................................... 200 Table 27: HSDPA Configuration Parameters...................................................................................... 209 Table 28: MAC-hs Parameters............................................................................................................ 209 Table 29: HSDPA Physical Layer Parameters.................................................................................... 210 Table 30: HSDPA Serving Cell Change Parameters ........................................................................... 210 Table 31: HSDPA Mobility Parameters............................................................................................... 211
Network Operations
Page Left Blank Intentionally
Network Operations
Document Revision History

This table identifies content revisions made to this document.
Date 10/15/2005 11/2005 12/19/05 01/05/06 03/14/06 06/02/06 06/7/06 Rev 0.1 0.4 0.9 1.0 1.0.1 1.2 1.3 Initial Draft Added sections up to Section 4.1 (Idle Mode Behavior) Document completion for review Initial Release IRAT section added Great details added to Load Control, Power Control, SHO, HSDPA sections. Reformat. Minor format change; minor parameter ranges change. Official release. Correction in HSDPA section based on comments from Stefan in Lucent. Revision Description Writer J. Derrick Smith J. Derrick Smith J. Derrick Smith J. Derrick Smith Hendry Tong Hendry Tong Hendry Tong Sponsor Mike Heubel Mike Heubel Mike Heubel Mike Heubel M. Heubel M. Heubel M. Heubel
RACI
This table identifies RACI team members.
Accountable Mike Heubel Responsible J. Derrick Smith Hendry Tong Consulted Market Engineering Regional Engineering National Field Support HQ Strategic Planning Lucent Technical Support Informed Mike Pietropola Lee Rudolph Adnan Naqvi John Dapper Ali Jabbary Lynn Pang Kevin Hetrick Warren Salek Gina Marshall-Johnson Lou Ficarra John Cooke John Cole Scott Sorice George Taylor Tim Ronzia Gus Malloian Kevin Chu David Black Mark Appel
Network Operations
Copyright (c) 2006 by Cingular Wireless Services, Inc. All rights reserved. No part of the contents of this document may be reproduced or transmitted in any form without the written permission of the publisher.
Network Services
1. About This Document

This section includes information about this document.
1.1
Purpose
The primary intention of this document is to serve as a common point for understanding and reference. This volume includes recommendations for all configurable RNC and Node B parameters available in the P1-Lite release. The recommendations provided within this document are the result of collaborative efforts between Cingular Wireless, Lucent Technologies, and other third-party vendors.
1.2
Scope
This document is primarily based upon the Lucent UTRAN implementation, focusing on the interaction between the User Equipment and UTRAN. For completeness, some facets of the Core Network are included e.g. Paging as well as Routing and Location Area Update procedures.
1.3
Audience
The audience for this document includes Cingular Market, Regional, and National level Engineers and Technicians responsible for Lucent UTRAN optimization and maintenance. The author of this document assumes that the reader has an introductory level understanding of WCDMA concepts (like spreading and scrambling) and UMTS processes. For assistance with attending training to increase competence in these areas, the reader is urged to contact their regional/national training coordinators or contact a Learning Edge representative.
1.4
Related Documentation
The following additional UTRAN Field Guides are related to this document and are currently available from the noted responsible person(s) or currently under development: RAN Field Guide Title Volume I : RF Design Guidelines Description Team Accountability Planning & Standards Responsible Person(s) Mark Reudink Ayman Mostafa
UTRAN design principles, guidelines, tools, and techniques. Includes AFP, ACP, Planning Tools, Propagation Tools, Drive Test and Post Processing Equipment/Software Packages. Guidelines for use of ancillary equipment (MCPA, Triplexer, Antenna, TMA,
Volume III: Equipment Engineering &

Planning & Standards
Ayman Mostafa Mike Heubel

Network Services
RAN Field Guide Title Hardware Configurations
Description etc.), Node B specifications and configurations. Internal link budget and FOA/lab test results. Vendorspecific information. UMTS optimization best practices, parameter trial results, and reports. Optimization tools and techniques. Vendor specific Guidelines and assumptions for dimensioning, forecasting, & provisioning. UTRAN Level 1, 2, & 3 counters and KPI descriptions. CES guidelines and capital planning process
Team Accountability Field Support
Responsible Person(s) Greg Scharosch
Volume IV: Optimization Solutions & Techniques
Planning & Standards Field Support
Kaushik Gohel Ayman Mostafa Mike Heubel Greg Scharosch
Volume V : NodeB Voice and Data Dimensioning
Business Planning Field Support Planning & Standards Field Support Business Planning Planning & Standards
Rick Fish Mike Heubel Greg Scharosch Kaushik Gohel Mike Heubel Greg Scharosch Michael Filley Mark Reudink
Volume VI: Key Performance Indicators (KPI) Volume VII: Capital Planning Guidelines
Volume VIII: RF Regulatory Mandates & Spectrum Planning Volume IX: Business Process
E911, Spectrum Planning, Interference mitigation, RF Exposure
Business Planning
Scott Burke
Processes related to MTI, quarterly mapping, and mapping requests
All
Drew Fonoroff (Rotating ownership based on necessary process updates)
1.5
Acronyms and Terms

Acronyms and terms are defined within the context of the information presented. Additional indexes/acronym identification tables will be added in future releases.
1.6
Trademarks
The trademarks used in this document are the property of their respective owners.
Network Services
1.7
Conventions
The following conventions are used throughout this document:
1.8
Contacts
For questions or comments about this document's technical content or to request changes to the document, contact either:
J. Derrick Smith, National RF Field Support Lucent UMTS, HQ RF Network Operations Desk: 404-236-6279 Wireless: 404-314-2822 E-mail: derrick.smith@cingular.com Hendry Tong, National RF Field Support Lucent UMTS, HQ RF Network Operations Desk: 404-236-5836 Wireless: 404-983-5437 E-mail: hendry.tong@cingular.com
Network Services
2. New Feature and New or Modified Parameter Lists

This section is reserved for future releases and will contain a list of all the new features and changes to parameters.
2.1
New Feature Lists

Links to new features introduced in the release as listed in corresponding section 3.
2.2
Parameters
This section will contain links to the description of any changes in existing parameters, and new parameters introduced by the new features.
2.3
KPI Introduction (NEW)

This section will contain links to the description of new performance monitoring peg counts and KPIs
Network Services
3. UMTS RF Design Fundamentals

This section provides background information on several UMTS design criteria which will be useful to the practicing engineer.
3.1
UE Capabilities
Multi-band support for the United States (800/1900 MHz) was not defined until Release 6 of the 3GPP specification. For this reason, Release 6 is the reference for this section.
3.1.1
UTRAN Frequency Bands
The frequency bands specified are shown in the table below including the separation (in MHz) between uplink and downlink frequencies. Cingular operates UMTS at 800 MHz (Band V) and 1900 MHz (Band II). The rest of the bands listed are included for completeness. Operating Band I II III IV V VI VII UL Frequencies 1920 - 1980 MHz 1850 - 1910 MHz 1710 - 1785 MHz 1710 - 1755 MHz 824 - 849 MHz 830 - 840 MHz 2500 - 2570 MHz DL Frequencies 2110 - 2170 MHz 1930 - 1990 MHz 1805 - 1880 MHz 2110 - 2155 MHz 869 - 894 MHz 875 - 885 MHz 2620 - 2690 MHz TX-RX Separation 190 MHz 80 MHz 95 MHz 400 MHz 45 MHz 45 MHz 120 MHz
Table 1: UTRAN Frequency Bands
3.1.2
Channel Numbering Scheme
The UTRA Absolute Radio Frequency Channel Number allows easy reference to the spectrum allocated to UMTS. Distinct UARFCNs are used for uplink and downlink frequencies as opposed to a single UARFCN for a pair of UL/DL frequencies. A UARFCN occupies 5 MHz of spectrum. The specification allows for two methods to be used to associate center carrier frequency to UARFCN. General UARFCN method. Each UARFCN is defined with a specific center frequency. Beginning at 0 Hz, the UARFCN is incremented by 1 with each increment of 200 kHz. The UARFCN corresponding to the center frequency is calculated by finding the product of 5 and the center frequency (in MHz); i.e. UARFCN = 5 * Frequency (MHz). When using the general method, this formula applies regardless of direction (uplink / downlink) and band. Additional Channels UARFCN method. The Additional Channels are specified according to the table below. These channels are shifted by 100 kHz relative to the general UARFCN definition. For Band II, the UARFCN is calculated by finding the product of 5 and the center carrier frequency (in MHz) minus 1850.1 MHz, i.e. UARFCN = 5 * (Frequency in MHz 1850.1 MHz). For Band V, the UARFCN is calculated by finding the product of 5 and the center carrier frequency (in MHz) minus 670.1 MHz, i.e. UARFCN = 5 * (Frequency in MHz 670.1 MHz).
Network Services
Either the General or Additional Channels method can be used to designate UARFCNs based upon where you choose to locate UMTS within your licensed spectrum.
UPLINK (UL) DOWNLINK (DL) UE transmit, Node B receive UE receive, Node B transmit UARFCN Carrier frequency [MHz] UARFCN Carrier frequency [MHz] (FUL)) (Note 1) (FDL)) (Note 2) 0.0 MHz FUL 3276.6 0.0 MHz FDL 3276.6 Nd = 5 * FDL Nu = 5 * FUL MHz MHz Note 1: FUL is the uplink frequency in MHz Note 2: FDL is the downlink frequency in MHz
Table 2: UARFCN Definition (General)
Band
II
UPLINK (UL) UE transmit, Node B receive UARFCN Carrier frequency [MHz] (FUL)) Nu = 5 * (FUL 1852.5, 1857.5, 1850.1 MHz) 1862.5, 1867.5, 1872.5, 1877.5, 1882.5, 1887.5, 1892.5, 1897.5, 1902.5, 1907.5 Nu = 5 * (FUL 826.5, 827.5, 831.5, 670.1 MHz) 832.5, 837.5, 842.5
DOWNLINK (DL) UE receive, Node B transmit UARFCN Carrier frequency [MHz] (FDL)) Nd = 5 * (FDL 1932.5, 1937.5, 1942.5, 1850.1 MHz) 1947.5, 1952.5, 1957.5, 1962.5, 1967.5, 1972.5, 1977.5, 1982.5, 1987.5 Nd = 5 * (FDL 670.1 MHz) 871.5, 872.5, 876.5, 877.5, 882.5, 887.5
Table 3: UARFCN Definition (Additional Channels)
3.1.3
UARFCN
The following UARFCN range shall be supported for each paired band. UL UARFCN 12 37 62 87 112 137 162 187 212 237 262 287
UL Center Frequency (MHz) 1852.5 1857.5 1862.5 1867.5 1872.5 1877.5 1882.5 1887.5 1892.5 1897.5 1902.5 1907.5
DL UARFCN 412 437 462 487 512 537 562 587 612 637 662 687
DL Center Frequency (MHz) 1932.5 1937.5 1942.5 1947.5 1952.5 1957.5 1962.5 1967.5 1972.5 1977.5 1982.5 1987.5
PCS / Cellular Band PCS - A PCS - A PCS - A PCS-D PCS-B PCS-B PCS-B PCS-E PCS-F PCS-C3 PCS-C4 PCS-C5
Network Services
782 787 807 812 837 862
826.5 827.5 831.5 832.5 837.5 842.5
1007 1012 1032 1037 1062 1087
871.5 872.5 876.5 877.5 882.5 887.5
Cellular - A Cellular - A Cellular - A Cellular - A Cellular - B Cellular - B
Table 4: UTRA Absolute Radio Frequency Channel Number
3.2
3.2.1
UE Transmit power
UE maximum output power
The following Power Classes define the nominal maximum output power. The nominal power defined is the broadband transmit power of the UE, i.e. the power in a bandwidth of at least (1+) times the chip rate of the radio access mode. The period of measurement shall be at least one timeslot.
Operating Band Band II Band V Power Class 1 Power Tol (dBm) (dB) +33 +33 Power Class 2 Power Tol (dBm) (dB) +27 +27 Power Class 3 Power Tol (dBm) (dB) +24 +1/-3 +24 +1/-3 Power Class 4 Power Tol (dBm) (dB) +21 +2/-2 +21 +2/-2
Table 5: UE Power Classes NOTE: power class 1 and 2 are reserved for future release.
3.3
UE Reference Sensitivity Level
The reference sensitivity level <REFSENS> is the minimum mean power received at the UE antenna port at which the Bit Error Ratio (BER) shall not exceed a specific value. Minimum requirement
Operating Band Unit DPCH_Ec <REFSENS> II dBm/3.84 MHz -115 IV dBm/3.84 MHz -117 NOTE 1. For Power class 3 this shall be at the maximum output power NOTE 2. For Power class 4 this shall be at the maximum output power <REFor> -104.7 -106.7
Table 6: Reference sensitivity
3.4
UE Categories
The 3GPP standards have defined 12 different categories of HSDPA-capable handsets. UEs with different level of complexity belong to different categories. Category 11 and 12 handsets (or PC cards) will only support 1 type of modulation and up to 5 simultaneous codes. Cingulars initial launch will include category 12 devices. Beginning from category 1 up to category 10, the UEs have increasing capabilities in terms of handling a larger number of simultaneous codes and larger buffer sizes. This translates to the ability to achieve higher bit rates for data-centric applications. Category 1-10 mobiles support 16-QAM modulation as well as QPSK.
Network Services Maximum number of HS-DSCH codes received
Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite Max # of bits of an HS-DSCH transport block received within an HS-DSCH TTI Total number of soft channel bits
HS-DSCH category
Minimum inter-TTI interval
Modulation Scheme Supported
Maximum Transfer Speed Supported
Category 1 Category 2 Category 3 Category 4 Category 5 Category 6 Category 7 Category 8 Category 9 Category 10 Category 11 Category 12
5 5 5 5 5 5 10 10 15 15 5 5
3 3 2 2 1 1 1 1 1 1 2 1
QPSK / 16-QAM QPSK / 16-QAM QPSK / 16-QAM QPSK / 16-QAM QPSK / 16-QAM QPSK / 16-QAM QPSK / 16-QAM QPSK / 16-QAM QPSK / 16-QAM QPSK / 16-QAM QPSK only QPSK only Table 7: UE Categories
7298 7298 7298 7298 7298 7298 14411 14411 20251 27952 3630 3630
19200 28800 28800 38400 57600 67200 115200 134400 172800 172800 14400 28800
1.2 Mbps 1.2 Mbps 1.8 Mbps 1.8 Mbps 3.6 Mbps 3.6 Mbps 7.2 Mbps 7.2 Mbps 10.1 Mbps 14.0 Mbps 0.9 Mbps 1.8 Mbps
3.5
UMTS RF Measurement
Throughout this field guide, many radio link performance indicators will be mentioned extensively thus it is worth listing them and describing briefly their meaning. For detailed information, refer to 3gpp specification 25.215.
3.5.1
RSSI
RSSI (Received Signal Strength Indicator), similar to what has been widely understood in GSM BCCH RSSI, is an indicator of signal strength or signal power received by UE. Even though one thing remains common for RSSI between UMTS and GSM RSSI in both system indicate signal strength of one frequency, the significant difference between UMTS and GSM in respect to RSSI stands to the fact that in GSM, BCCH RSSI is measured for one particular BTS whilst in UMTS, RSSI is measured over the whole band of 5Mhz and this RSSI measurement can be influenced by multiple NodeB. Therefore, RSSI in UMTS can not really tell the quality or coverage of certain cell. Nevertheless, RSSI is still useful as it is reference to calculate Ec/Io a key quality indicator of signal link (such as CPICH). RSSI is often also referred as Received total wideband power (RTWP). This is simply the total received power (including noise generated in the receiver) within the bandwidth defined by the pulse shaping filter. It is most important for estimating loading or some unexpected interference in the network, but not so important concerning link performance.
3.5.2
CPICH RSCP
RSCP stands for Received Signal Code Power. This is the received power of the CPICH channel as measured by the UE. It can be used mainly to estimate the path loss, since the transmission power of the CPICH is either known or can be read from the system information. (The CPICH is a fixed-rate (30 kbit/s, SF=256) downlink physical channel that carries a predefined bit/symbol sequence. It is scrambled by a cell-specific primary scrambling code.)
Network Services
3.5.3
Eb/N0 and Orthogonality,
Originally, Eb/N0 meant simply bit energy divided by noise spectral density. However, over time the expression Eb/N0 has acquired an additional meaning. One reason is the fact that in CDMA the interference spectral density is added to the noise spectral density, since the interference is noise, due, for example, to spreading. Thus, N0 can usually be replaced by I0, interference plus noise density. The performance indicator Eb/N0 is always related to some quality (BLER) target. Following equation is a basic example of how to calculate Eb/N0 in uplink. Suppose that the signal is received at constant power Prx and received interference power is I. Assume that user bit rate is R and bandwidth is W. Now, the interference lies uniformly on the bandwidth of W (Hz) (equal to the chip rate) and the bit energy is Prx * (1/R) [Ws], thus
Prx Eb R = W o Prx = I No R I W
The target of the fast power control in WCDMA is to keep the received Eb/N0 constant. Due to the fast feedback loop (1500 Hz) this is fairly successful. It means that for a chosen service, chosen channel conditions and chosen required BLER, the received power on the traffic channel divided by the interfering power is approximately constant. In downlink the Eb/N0 is defined in another way, because the synchronised orthogonal codes reduce the interference from the serving cell (or cells, in soft handover). In downlink the Eb/N0 is calculated by the model
Eb W Prx = N o R I own (1 ) +I oth + PN

where Iown is the total power received from the serving cell, Ioth is the total power received from the surrounding cells, and PN is the noise power (thermal and equipment). The factor is the so-called orthogonality factor, which depends on the multipath conditions. The codes are fully orthogonal, thus in the case of no multipath the interference from the serving cell is cancelled and = 1. If there are instantaneously two equally strong propagation paths, then only half of the interference is cancelled from the receiver point of view and = 0.5 at this instant. Notice that Eb/N0 and should always be kept together, because in calculating the DL capacity or spectral efficiency these together are the inputs that model the link-level performance. Using several scrambling codes in one cell naturally destroys the orthogonality.
3.5.4
Ec/I0
Ec/I0 is the received chip energy relative to the total power spectral density. Ec: Io:
Average energy per PN chip = RSCP of common pilot channel For CPICH Ec: Depends on power and path loss Constant for a given power and path loss. Ec is not dependent on load the total received power spectral density, including signal and interference, as measured at the UE antenna connector. In many cases, Io is considered equal to No, i.e.: RSSI or RTWP. depends on ALL channel power, All cells, and path loss
CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions Page 20 of 248 (c) 2006 Cingular Wireless
Network Services
depends on same-cell and other-cell loading depends on external interference Ec/Io = Eb/No Processing Gain = Eb/No 10log(3.84 mbps/bit rate) [dB]
Ec/No provide no info on channel quality as it is not even an measurement on traffic channel, rather it is an indicator of relative position of UE with respect to various cell in the system and will be used for handover. It is typically used as a link performance indicator for signals that are for, e.g., CPICH, AICH and PICH. Thus it is mostly used as CPICH Ec/Io in this field guide. CPICH Ec/N0 Received energy per chip divided by the power density in the band. This is the most important UE measurement in WCDMA for network planning purposes, not only because it is typically the basic coverage indicator, but also because the accuracy is good, since the measurement can be done on baseband. Theoretically it is identical to CPICH RSCP/RSSI. CPICH Ec/Io = CPICH Ec/No = CPICH RSCP CPICH RSSI You can see such usage in many drive test tool measurement report. [dB]
3.5.5
SIR
Signal to Interference Ratio, defined as (RSCP/ISCP) * SF, where RSCP is the Received Signal Code Power on the DPCCH, ISCP is the Interference Signal Code Power on the DPCCH, and SF is the spreading factor on the DPCCH, i.e. 256. The reference point for the SIR measurement is the antenna connector. For one bearer service the Eb/N0 of the transport channel can be estimated from SIR according to the equation, which includes both the multi-code transmission and the overhead of the DPCCH in the energy per bit computation:
user Eb UL,DPCCH RDCH 20 log c 10 log SFDPCCH = SIRactual 10 log d 2 SF NoDCH DPDCH c N + RDPDCH d
Where c (DPCCH gain factor), d (DPDCH gain factor), RDPDCH (DPDCH bit rate) and SFDPDCH are produced by the admission control (AC) in the RNC considering the maximum bit rate of the transport channel; and N is the number of DPDCH's employed in the multi-code transmission. These parameters are system internal parameters in Siemens system currently, and will be mentioned again later in sections describing Random Access and Admission Control.
3.5.6
Transmitted Carrier Power (TCP)
This is the ratio between the total transmitted power and the maximum transmission power of a UTRAN access point (BS). It can be used in analyzing the downlink performance of dedicated channels, as it indicates the total BS power used.
Network Services
3.5.7
Transmitted code power
This is the transmitted power on one channelization code on a given scrambling code on a given carrier. This can be used in analyzing the downlink performance of dedicated channels.
3.5.8
Transport channel BER
The transport channel BER is an estimate for the block error rate. It is based on the CRC evaluation on each transport block after radio link combination. In uplink, it is an estimation of the average bit error rate of DPDCH.
3.5.9
Physical channel BER
The physical channel BER is an estimation of the average bit error rate on the DPCCH. This is often called raw BER or uncoded BER.
3.5.10 BLER
BLER is the long-term average block error rate calculated for the transport blocks. The transport block is considered erroneous if it has at least one bit error. The system knows the correctness of the blocks with very high reliability through the CRC. Note that BLER is not a mandatory measurement for the UTRAN.
3.5.11 UE transmitted power

This is very important as it can be used to verify the power control performance, together with the SIR and BLER estimates at the BS.
3.6
UMTS Link Budget
The link budget forms the key element for the dimensioning process. This process provides the cell capacity of a UMTS cell and the radius of the cell, which has to be chosen to manage the traffic density and the performance level specified for the network. It also helps to dimension the required coverage, capacity, and quality of service requirement in the network. UMTS link budgets vary according to the volume of data being transmitted and the planner must always be aware that the RF network plan will also need to be optimized with regard to a wide range of varying data speeds of subscribers in the network. This is one of the most important factors in maintaining the required network coverage. The coverage of a cell, corresponding to a traffic density, can be defined as the common coverage of each service and subscribers that are present within that traffic density. Coverage/Capacity issues for a mixed traffic density model are complicated and will not be discussed here. It is expected that the engineer continue his/her study of link budgets beyond this document for additional link budget analysis of more complex scenarios. This document will focus on the study of a single UMTS service. UMTS macro cell coverage is uplink limited, because UE power levels are limited (in our case to 24 dBm ~ 250 mW). The downlink limits the available capacity of the cell, as NodeB power (40W total PA power) has to be divided among all users. In a network environment both coverage and capacity are interlinked by interference. So by improving one side of the equation one would decrease the other side. The object of the link budget design is to calculate the maximum cell size under given criteria: Type of service (data type and speed) Type of environment (terrain, building penetration) Behavior and type of UE (speed, max power level)
NetOps-xxxxxND-00167 Rev. 1.3 06/02/06 CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions Page 22 of 248 (c) 2006 Cingular Wireless
Network Services
System configurations (antennas, cable losses, handover gain) Required coverage probability Financial and economic factors (use of more expensive and better quality equipment and services as opposed to the cheapest) Below is an example of the process required to develop a UMTS link budget and a sample of an actual UMTS link budget. Once the Maximum Cell Range is calculated, one can insert this into a defined propagation model to obtain a cell radius for the UMTS service. Some of the values can be debated but this is presented only to give an idea of the calculation method.
UPLINK BUDGET
User Equipment UE Antenna losses Body loss Antenna RX Sensitivity RX Noise Figure Penetration Losses EIRP Transmitted Power UE Gains Antenna Receiver Sensitivity Node B Node B Antenna losses Node B RX Noise Figure RX Noise Density RX Noise Power Penetration Losses Interference Margin Cable, connector, and combiner losses Thermal noise density Fast-fading margin
Required Eb/No Node B Gains Antenna Handover
DOWNLINK BUDGET
User Equipment Loading Factor UE Antenna losses Body loss Antenna RX Sensitivity RX Noise Figure Penetration Losses
Maximum Acceptable Uplink Pathloss
Node B
Environment Correction
Reliability Margin
Uplink Pathloss
Node B Antenna losses Node B RX Noise Figure RX Noise Density RX Noise Power Penetration Losses Interference Margin Cable, connector, and combiner losses Thermal noise density Fast-fading margin
Required Eb/No
Receiver Sensitivity
EIRP Node B Gains Antenna Handover Output Power per Link
UE Gains Antenna
Figure 1: UMTS Link Budget Considerations and Interactions
Network Services
Carrier Frequency Channel Bandwidth No = kT (k = 1.38x10-23 / T = 290 K) Noise Bandwidth (B) Noise in Channel Bandwidth (No * NF * B) Mobile Station EIRP CPICH Power Node B Noise Figure (NF) Node B Antenna Gain Node B Transmit Cable Loss Node B Combiner Loss Node B Antenna Slant Loss Node B Receive Cable Loss CPICH EIRP Node B Antenna Height Data rate Processing Gain Target Eb/No Receiver Sensitivity Load Factor Interference Margin Maximum Allowable Path Loss Body Loss Margin Building/Vehicle Penetration Margin Shadowing Standard Deviation Cell Area Reliability Target Cell Edge Reliability Target Shadowing Margin Handover Gain/Loss Total Required Link Margin Maximum Cell Range
unit MHz MHz dBm/Hz dBHz
UMTS CS 12.2 1900 3.84 -174.0 65.84 104.63 24 36 3.5 18 3 0 1.5 3 49.5 20 12.2 24.98 7 122.61 50% 3.0 160.11 3.00 10.00 8.00 0.95 0.91 10.70 4.10 19.60 140.51
UMTS PS 64 1900 3.84 -174.0 65.84 104.63 24 36 3.5 18 3 0 1.5 3 49.5 20 64 17.78 5 117.42 50% 3.0 154.92 3.00 10.00 8.00 0.95 0.91 10.70 4.10 19.60 135.32
UMTS PS 128 1900 3.84 -174.0 65.84 104.63 24 36 3.5 18 3 0 1.5 3 49.5 20 128 14.77 4.5 114.91 50% 3.0 152.41 3.00 10.00 8.00 0.95 0.91 10.70 4.10 19.60 132.81
UMTS PS 384 1900 3.84 -174.0 65.84 104.63 24 36 3.5 18 3 0 1.5 3 49.5 20 384 10.00 3 111.63 50% 3.0 149.13 3.00 10.00 8.00 0.95 0.91 10.70 4.10 19.60 129.53
Formula Descriptions a b c = 10*LOG10(1.38E-23*290*1000) d = 10*LOG10(b * 1000000) e=c+d+h f g h i j k l m n=g+i-j-l o p q= 10*LOG10((b*1000000)/(p*1000)) r s=e-q+r t u = 10*LOG10(1/(1-t)) v=f+i-l-m m1 m2 Given Given Calculated using Reudnik curves m3 m4 m5 = m1 + m2 + m3 - m4 MCR = v - m5
dBm dBm dBm dBi dB dB dB dB dBm m kbps dB dB dBm % dB dB dB dB dB % % dB dB dB dB
Table 8: Sample Link Budget

Network Services
4. UTRAN Processes, Procedures & Recommended Parameter Settings

This section details the normal operating UTRAN processes, procedures, and recommended parameter settings. Within this section, optimal (launch configured) parameter settings will be provided and based upon the possibility of transitioning states. This section has been organized to follow the cycle that a UE would go through for completing a call (including mobility). These actions (i.e states) will include: Powering on and camping on a cell (including system determination) Cell selection/reselection Load control (includes admission control, congestion control, and bit rate adaptation) Power control Soft handover (SHO) for mobility within UTRAN Inter Radio Access Technology (IRAT) handover between GSM and UMTS HSDPA See the illustration below.
Figure 2: Overview of Possible State Transitions
Network Services
4.1
Idle Mode Behavior
In the idle mode (defined by TS 25.304 v 6.7.0), after the UE is switched on, it selects (either automatically or manually) a PLMN to contact. The UE looks for a suitable cell of the chosen PLMN, chooses that cell to provide available services and tunes to its control channel. This is defined as camping on a cell. The UE will, if necessary, then register its presence in the registration area of the chosen cell. As an outcome of a successful Location Registration, the selected PLMN becomes the registered PLMN. If the UE finds a more suitable cell, it reselects onto that cell and camps on it. It is important to note that camping on the wrong cell will waste radio resources by causing high interference when accessing the network. If the new cell is in a different registration area, location registration is also performed.
4.1.1
System Acquisition
After the UE powers on, it has to lock to the Broadcast Channel for information about the services available to the UE, the radio network parameters, and the core network parameters. The broadcast channel is sent by each cell (i.e. sector) and it covers a specific area. The broadcast channel is used to broadcast System Information to all UEs within the coverage area. In order to lock onto the broadcast channel, the UE needs to know the timing reference of the broadcast channel. This is accomplished in 3 steps. Once the UE locks onto the BCCH, it can obtain system and cell information so that it can obtain system services. However, it is important to remember that the UMTS (FDD) downlink frame structure is based on 10 ms frames. Each frame is subdivided into 15 slots (made up of 2560 chips. This provides a chip rate of 2560*15 / 10 ms = 3.84 Mchips/sec.
Figure 3: UMTS DL Frame Structure Since GPS is not mandated for UMTS deployment, no central clock is available for synchronization. Therefore, two channels have been dedicated on the physical layer to assist the UE acquire timing synchronization. These two channels are the Primary Synchronization Channel (P-SCH) and the Secondary Synchronization Channel (S-SCH). Once the UE achieves synchronization, it still needs to detect the Cell Specific Scrambling Code (CSSC) that each cell/sector is using to scramble information. The CSSC is broadcast by using another channel, Common Pilot Channel (CPICH). The CPICH is time aligned with the broadcast channel, which resides on the physical layer channel called the Primary Common Control Physical Channel (PCCPCH). Therefore, the UE obtains the timing and synchronization required to decipher the CSSC and use this information to decode the broadcast channel.
Network Services
4.1.1.1
UMTS Cell Search Procedure
The procedure of searching for a cell and synchronizing to its downlink scrambling code is commonly referred to as cell search. Although the internals of this are not really relevant for cell selection and reselection, it directly affects its performance as it is used as the underlying procedure to identify and measure the neighbor cells. The behavior of the cell search algorithms is largely impacted by the power settings for the 3 physical channels involved in the process: the Primary Synchronization Channel (P-SCH), the Secondary Synchronization Channel (S-SCH) and the Primary Common Pilot Channel (P-CPICH). See the recommended settings for these parameters in the table below. Note that unlike the P-CPICH, the two synchronization channels are not scrambled by the primary downlink scrambling code. Parent Object LCell Parameter Name pCPICHPower Recommended Setting 36 dBm (40 W PA) 33 dBm (20 W PA) 10% of Total PA Power
Range -10 to +50 [dBm] 0.1 dB steps
Short Description Total power allocated to the primary common pilot channel (CPICH) in dBm. Important for the 3rd stage of cell search. Power allocated to the primary synchronization channel (P-SCH). The value is given relative to the primary CPICH power (dB). Important for the 1st stage of cell search (slot synchronization). Power allocated to the secondary synchronization channel (S-SCH). The value is given relative to the primary CPICH power (dB). Important for the 2nd stage of cell search (frame synchronization and code group identification).
LCell
pSCHPower
-3.0 dB (33 dBm for 40 W PA 30 dBm for 20 W PA)
-35 to +15 [dB] 0.1 dB steps
LCell
sSCHPower
-5.0 dB (31 dBm for 40 W PA 28 dBm for 20 W PA)
-35 to +15 [dB] 0.1 dB steps
Table 9: CPICH and SCH Power Settings for Cell Search Generally, the process of cell search can be divided into 3 stages: 1. Slot synchronization by using the P-SCH 2. Frame synchronization and code group identification utilizing the S-SCH 3. Scrambling code identification on the P-CPICH
4.1.1.1.1
Slot Synchronization
The first step that occurs when a mobile is powered on is obtaining timing information and synchronizing with the system. The synchronization channels are utilized for this. The UE needs to obtain some timing information on where the frame begins and ends. Once the frame timing is understood, the Common Pilot Channel (CPICH), which is sent on the same time alignment, can be used to obtain the cells scrambling code. The acquisition needs to take as minimum time as possible. The SCH consists of 2 sub-channels. The primary channel is used to obtain slot level synchronization. Note that the synchronization channel does not carry any data. During the slot synchronization process, the UE searches for the cell which has the least path loss. This is accomplished by looking for the primary SCH code, which is identical for all Node Bs. The primary SCH contains a 256-chip code word which is sent
Network Services
without any changes (no data modulation like spreading, etc.). As no timing information is available, the mobile relies on matched filters to get the best possible match. The 256-chip sequence is known by the UE in advance. The UE correlates the received signal with this sequence over 1 slot. The correlation outputs are then combined over several slots and the largest peak is chosen as the slot boundary.
Figure 4: 256-chip Sequence Correlation Once it matches (i.e. correlated over 15 slots) with the Primary SCH, then the UE has obtained slot synchronization, since the transmission of the primary SCH is aligned with PCCPCH (Primary Common Control Physical Channel broadcast channel) slot transmission. The CPICH is also aligned with this channel. At this point, the mobile has acquired the system. However, it does not know which cell it has locked to. This process is illustrated below.
Figure 5: Cell Search Stage 1 Slot Synchronization
Network Services
4.1.1.1.2
Frame Synchronization
Although the UE has acquired the system via slot synchronization, it still needs to detect the beginning of the frame. It does this by using the Secondary SCH in a method similar to the process defined for slot synchronization. The Secondary SCH (S-SCH) is a discontinuous transmission channel which transmits only during the first 256 chips of a slot. The S-SCH uses code words as well, except there are 64 defined and each synchronization sequence is made up of 15 256-chip orthogonal codes. The UE correlates the received signal with a block of 15 sequences over 1 frame period. The largest peak is chosen as the frame boundary. Once the UE has decoded 15 successive SCH codes, it not only knows where the frame begins, but the Code Group as well. The S-SCH sequences are arranged so each sequence maps to a base station code group, which consists of 8 scrambling codes. Once the UE obtains frame synchronization, this narrows down the search for scrambling codes used for the CPICH from 512 to a modest 8. Now the UE can begin Stage 3, Scrambling Code Identification on the P-CPICH.
Figure 6: Cell Search Stage 2 - Frame Synchronization 4.1.1.1.3 Scrambling Code Identification
The UE determines the exact scrambling code used by the Node B using the Primary Common Pilot Channel (P-CPICH). Each of the 64 possible sequences identified by the S-SCH maps described above maps to 1 of 8 possible Cell Specific Scrambling Codes (CSSC). The UE is able to detect the P-CPICH since it knows that the pilot symbols are spread with SF=256 and scrambled with 1 of the 8 scrambling codes found in the previous step. The UE does symbol-by-symbol correlation to determine the exact scrambling code used by the cell. The outputs are combined over several pilot symbols and slots. The largest peak is chosen as the scrambling code. Thus the scrambling code used by the cell has been obtained by the UE. Now the UE can decode the broadcast channel (on the PCCPCH) as this is time aligned with the P-CPICH and. Proper Scrambling Code and S-SCH planning is required to ensure proper reuse of scrambling codes within the network.
Network Services
Figure 7: Cell Search Stage 3 - Scrambling Code Identification Now the UE can find its subscribed Public Land Mobile Network (PLMN) and continue reading System Information on the BCCH.
4.1.1.2
Planning for Good Network Acquisition Performance
If problems during the cell search procedure occur in areas of good coverage, the power settings of the involved channels should be examined. This can be done using drive test equipment which allows one to verify power settings for pilot (P-CPICH) and synchronization channels (P-SCH and S-SCH) as defined in [Table 9: CPICH and SCH Power Settings for Cell Search] and determine which stage fails. Lucent recommends setting the P-CPICH to at least 10% of the maximum output power of the power amplifier. This recommendation allows for better initial search acquisition and identification of the cell specific scrambling code. Notice in the chart below how the acquisition time degrades as the P-CPICH power is decreased. It should also be noted that the channel powers are not only relevant for the initial cell search of the UE, but also affects the behavior during cell reselection and especially during soft handover (target cell search) in connected mode (to be discussed in later sections). This means that lower power settings may still provide sufficient selection and reselection service but severely degrade the performance during soft handover because of the prolonged cell search process. However, as slower cell search during soft HO may lead to a very late addition of new HO legs, it can severely degrade system performance. Therefore, power settings cannot only be based on the cell selection/reselection process but must also take the cell search during soft handover into account (see target search column in Figure 7 below). Furthermore, the load of the own cell as well as surrounding cells must be considered as interference for the UE.
Network Services
Figure 8: Acquisition Time versus CPICH Power Allocation The drive test equipment also provides a means for evaluating scrambling code assignment to the cell which affects the cell search behavior in the second and third stage of the synchronization process. Proper scrambling code planning should guarantee that it is not possible to receive two cells with a sufficient receive level and the same scrambling code in any location of the network.
4.1.2
PLMN Selection
During PLMN selection, based on the list of allowed PLMN types and a list of PLMN identities in priority order, the particular PLMN may be selected either automatically or manually. In the System Information on the Broadcast Control Channel (BCCH), the UE can receive a PLMN Identity. In the UTRA case, the UE will scan all RF channels in the UTRA band according to its capabilities to find available PLMNs. On each carrier, the UE will search for the strongest cell and read its system information (in order to find out which PLMN the cell belongs). If the UE can read one or several PLMN identities in the strongest cell, each PLMN will be reported as a high quality PLMN (without the RSCP value), provided that the following high quality criterion is fulfilled: The measured primary CPICH RSCP value shall be greater than or equal to only) -95 dBm. (FDD
Found PLMNs that do not satisfy the high quality criterion, but for which the UE has been able to read the PLMN identities are reported along with the CPICH RSCP value to the NAS. The search for PLMNs on the rest of the carriers may be stopped on request of the NAS. The UE may optimize this search by using stored information of carrier frequencies and optionally information on cell parameters such as scrambling codes from previously received measurement control information elements. Once the UE has selected a PLMN, the cell selection procedure shall be performed in order to select a suitable cell of that PLMN to camp on.
4.1.3
Cell Selection & Reselection
Cell selection and reselection is one of the idle mode tasks a UE is supposed to perform. In UMTS, cell reselection is also performed in RRC connected mode. The RRC connected mode states relevant to cell reselection in Lucents current software version (03.01 P1 Lite) are the URA_PCH and CELL_FACH RRC states. Figure 9 below shows an overview of processes involving cell selection and reselection.
Network Services
go here whenever a new PLMN is selected no cell information stored for the PLMN
cell information stored for the PLMN Stored information Cell Selection no suitable cell found
no suitable cell found
Initial Cell Selection
suitable cell found
suitable cell found no suitable cell found
Cell Selection when leaving connected mode
suitable cell found
Camped normally
NAS indicates that registration on selected PLMN is rejected (except with cause #14 or #15 [5][16])
return to idle mode
leave idle mode
trigger suitable cell found go here when no USIM in the UE
Connected mode
Cell Reselection Evaluation Process
no suitable cell found
Any Cell Selection
Figure 9: Cell Selection/Reselection Process 4.1.3.1 System Information Broadcast (SIB) Parameters for Cell Selection and Reselection
Once the UE successfully synchronizes to the CPICH scrambling code of the Node B, it starts to decode the system information broadcast (SIB) on the BCH. The UE can use the broadcast information to send access messages to the network. This may be to make phone calls, start data sessions, or register location changes. This broadcast information originates from the Core Network, from the RNCs, and from the Node Bs. The System Information messages are sent on a BCCH logical channel, which can be mapped to the BCH or FACH transport channel. The system information carries System Information Blocks (SIBs) which group together system information of the same nature. The SIBs contain static information as well as dynamic information. Dynamic (i.e. frequently changing) parameters are grouped into different SIBs from the more static parameters. One System Information message can carry either several SIBs or only part of one SIB, depending on the size of the SIBs to be transmitted. One System Information message will always fit into the size of a BCH or FACH transport block. All the system information blocks in a cell are pointed to by a Master Information Block (MIB). The MIB always occurs in a fixed schedule and also contains some static information. As the information in the SIBs could change, the MIB contains information on any recent changes to SIBs as well. Thus the UE can know if any SIB has changed and retrieve this information. The system information blocks are organized as a tree illustrated below.
Network Services
Figure 10: System Information Block (SIB) Mapping SIB3 and SIB4 contain parameters for cell selection and reselection to be used in idle and connected modes respectively. For the idle mode the UE extracts the parameter settings from SIB3. While in connected mode, the UE looks for SIB4 for cell reselection parameters but reverts to SIB3 if it doesnt find SIB4. It is important to note that the power setting for the P-CCPCH has to be high enough to allow a proper decoding of the BCH at the UE. If there is any reason for cell selection/reselection parameters for UE in URA_PCH or Cell_FACH state to be different from those in idle mode, the parameter sIB3EnableSIB4Indicator can be used (i.e. set to TRUE) to enable broadcast of system information on cell reselection on SIB4. The recommended value is FALSE, assuming that initially, the cell selection and reselection for idle and connected modes are the same. In that case the UE will use the parameters send on SIB3 for the connected modes setting as well. For parameters related to SIB3, there are similar parameter settings for SIB4 and the parameter names reflect this by changing the sIB3 prefix to sIB4. Lucent has implemented a Master Information Block (MIB) and the following System Information Blocks: System Information Block Type 1 System Information Block Type 2 System Information Block Type 3
Network Services
System Information Block Type 5 System Information Block Type 7 System Information Block Type 11 System Information Block Type 12 See 3GPP TS34.108 v6.0.0 for default SIB parameters and messages for each information block type. 4.1.3.2 Cell Selection (i.e. Camping on a Suitable Cell)
The cell selection process can be based on stored cell information is such information is available in the UE. If this information is not available or no suitable cell was found using the stored information, an initial cell selection should be invoked. For this procedure the UE shall scan all available RF channels to find a suitable cell using the cell selection criterion described below. The cell selection criterion S used for cell selection/reselection is fulfilled when: UMTS FDD Cells: Squal > 0 AND Srxlev > 0 GSM Cells: Srxlev > 0 Squal is a cell selection quality value and is derived from the received CPICH Ec/No [dB], which is only applicable for FDD cells. Srxlev is the cell selection received level and is determined by CPICH RSCP [dBm] for FDD cells and by the signal strength of the BCCH channel for GSM cells. In GSM, Srxlev is also known as the C1 parameter. For UTRAN cells Squal and Srxlev are defined by the equations: Squal = Qqualmeas Qqualmin Srxlev = Qrxlevmeas Qrxlevmin Pcompensation Qqualmeas and Qrxlevmeas are the UE measured cell quality value (CPICH Ec/No) and cell RX level value (CPICH RSCP), respectively. Qqualmin and Qrxlevmin represent the minimum required quality value and minimum required receive level in the cell, which needs to be exceeded to fulfill the above selection criteria. The RX level term includes the power compensation value, which specifies the difference of the maximum allowed TX power on the RACH (UE_TXPWR_MAX_RACH) and P_MAX if this difference is larger than zero. P_MAX denotes the maximum RF output power based upon the UE power class (see Table 5: UE Power Classes). Pcompensation = max(UE_TXPWR_MAX_RACH P_MAX,0) (dB)
This means that if the mobile can transmit at a maximum power which is less than the maximum allowed TX power for that cell, the cell selection RX level value will be reduced by that margin Pcompensation. For GSM cells, cell selection is based on Srxlev (C1 Criterion) defined by: Srxlev = Qrxlevmeas Qrxlevmin Pcompensation where Qrxlevmeas is the UE measured RX level measured for the BCCH.. Qrxlevmin represents the minimum required receive level in the cell given by the GSM parameter RXLEV_ACCESS_MIN. Pcompensation specifies the difference of the maximum allowed TX power of the UE in GSM mode (MS_TXPWR_MAX_CCH) and the maximum RF output power of the UE in GSM mode defined by its GSM power class, P. Pcompensation = max(MS_TXPWR_MAX_CCH P_MAX,0)
NetOps-xxxxxND-00167 Rev. 1.3 06/02/06 CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions
(dB)
Network Services
4.1.3.2.1
Cell Selection Parameter Settings
The values of cell selection related parameters are presented in the table below and those parameters market with (*) also have SIB4 counterpart values which should be set if SIB4 is enabled for connected mode.
SIB Information Element Cell selection and reselection quality measure Parameter Range CPICH Ec/No, CPICH RSCP Recommendation Description Choice of measurement (CPICH Ec/No or CPICH RSCP) to use as quality measure for FDD cells. This is also sent in SIB 11/12. Both occurrences should be the same value. Ec/No [dB] RSCP [dBm] Maximum UE Transmit Power
cellSelAndResQualMeas
cPICHECNO
Qqualmin Qrxlevmin Maximum allowed UL TX Power
sIB3QQualMin* sIB3QRXLevMin* sIB3MaxAllowed ULTxPower*
-24 to 0 -115 to -25 , 2 dBm steps -50 to 33, 1 dBm steps
-19 dB -115 dBm 24 dBm
Table 10: Cell Selection Parameter Recommendations cellSelAndResQualMeas There are 2 possible options for the selection/reselection quality measure. Either CPICH Ec/No or CPICH RSCP can be used. Lucent has recommended that CPICH Ec/No be used since it is considered to be the most relevant quality indicator, which is also used for handover decisions.
sIB3QQualMin If this parameter is too small, the UE may camp on a cell with very low quality and may not be able to receive reliable service. If the parameter is too large, the UE will prematurely declare the cell unsuitable and may unnecessarily select another PLMN. A cell whose CPICH Ec/No is below Qqualmin is said to be unsuitable. If no suitable cell is found for at least 12 sec (or 4 sec when in Cell_FACH state), the UE will attempt to find a suitable cell in another PLMN with the same or a different RAT. sIB3QRXLevMin If this parameter is set too low, the UE may camp on a cell with very low quality and may not be able to receive reliable service. If set too high, the UE will prematurely declare the cell unsuitable and may unnecessarily select another PLMN. Qrxlevmin affects the cell selection criteria. The formula above provides a necessary (but not sufficient) condition for cell selection. Qrxlevmin is used to ensure that the selected cells reverse link path loss does not exceed the maximum tolerable path loss. Qrxlevmin should be set to a value no less than: Qrxlevmin >= Receiver noise power + Qqualmin >= -174 [dBm/Hz] + 10 log (3.84*106) [Hz] + NFUE [dB] + Qqualmin [dB] >= -108.16 dBm + 8 dB -19 dB = -119.16 dBm Otherwise, the Srxlev computation will not affect the cell reselection suitability criteria.
Network Services
sIBMaxAllowed ULTxPower The parameter sIB3/4MaxAllowedULTxPower has direct impact on RACH coverage. This parameter should be set to a value corresponding to the power class of the UE and not be changed unless required for special optimization situations.
4.1.3.2.2
Impact on Related Performance Measurements
As cell selection is executed in the UE without any signaling to the network, it is not possible to see any impact on performance measurements. However, if the thresholds for quality and level for the cell selection criteria are chosen too high, then the UE may not be able to select/reselect a cell in large parts of the coverage area. From the system performance this issue may become apparent in decreased network traffic. For the maximum power parameter, behavior will not be reflected by performance measurements but it can be verified using test mobiles if RACH coverage problems are evident.
4.1.3.3
Location Area / Routing Area Update
After the UE has found a suitable cell, it will camp on that cell. The next step is to perform Location Area (LA) and/or Routing Area (RA) update, if needed. This is not necessary if the LA or RA has not changed since the last time the UE was powered off. In this instance, only PLMN registration is required. LA/RA information is sent in SIB1 on the BCCH, along with other parameters. LA/RA can be triggered for 3 reasons. Normal LA/RA Update Periodic LA/RA Update IMSI Attach/Detach 4.1.3.3.1 Normal LA/RA Update
The normal location updating procedure is used to update the registration of the actual Location Area / Routing Area of the UE in the network. Normal location updating is perform when the UE moves into a new LA/RA, switches on, or leaves connected mode. The location updating procedure is always initiated by the UE. To limit the number of location updating attempts made, where location updating is unsuccessful, an attempt counter is used. The attempt counter is reset when: The UE is switched on. A SIM/USIM card is inserted. The location updating procedure is successful. In this case, the update status is set to UPDATED in the SIM/USIM and the Location Area Identification (LAI) is stored in the SIM/USIM. In the case that the UE is initiating an emergency call but, due to cell reselection or redirection by the network, it moves to a different LAI, then the UE may delay the location updating procedure in the new LA/RA until after the emergency call is completed.
Network Services
4.1.3.3.2
Periodic LA/RA Update
Periodic updating will be used to periodically notify the network on the availability status of the UE. Periodic updating is performed by using the location updating procedure. The procedure is controlled by the timer T3212 in the UE, which gives the time interval between two consecutive periodic location updates. The timer starts each time the UE enters the idle mode. The timer is stopped and set to its initial value when: A LOCATION UPDATING ACCEPT or LOCATION UPDATING REJECT message is received An AUTHENTICATION REJECT message is received UE has responded to paging message UE has been deactivated (i.e. equipment powered off or SIM/USIM removed). When the timer T3212 expires, the location updating procedure is started and the timer is set to its initial value for the next start. 4.1.3.3.3 IMSI Attach/Detach
This procedure is similar to the IMSI attach/detach procedure in GSM. It is used to indicate that the IMSI is active in the network. This helps to avoid unnecessary paging for a UE that is powered off. Usage of this function is controlled by system parameters and a flag (ATT) is broadcast in the CS domain specific system information element to indicate whether the attach and detach procedures are required to be used or not. The IMSI attach procedure is invoked if the detach/attach procedures are required by the network and an IMSI is activated in a mobile station (i.e. activation of a mobile station with plug-in SIM/USIM, insertion of a card in a card-operated mobile station etc.) within coverage area from the network or a mobile station with an IMSI activated outside the coverage area enters the coverage area. The IMSI attach procedure is used only if the update status is UPDATED and if the stored Location Area Identification is the same as the one which is actually broadcasted on the BCCH of the current serving cell.
4.1.3.4
Cell Reselection
This section provides the algorithms and recommended parameter settings related to cell reselection while the UE is in idle mode. These translations can also be attributed to UEs in URA_PCH and CELL_FACH state. Cell reselection is performed continuously to ensure that the UE is camping on the best available cell. Since Cingular will not be making use of Hierarchical Cell Structures (HCS), this section does not consider cell reselection processes associated with this feature.
4.1.3.4.1
Discontinuous Reception (DRX)
In order to understand cell reselection, discontinuous reception should be addressed. Discontinuous Reception (DRX) is a procedure the UE may use in idle mode in order to reduce power consumption. When DRX is used the UE needs only to monitor one Page Indicator (PI) in one Paging Occasion per DRX cycle. The location of the PI and Paging Occasion can be calculated from the IMSI of the UE. Paging will be discussed in a later section. The DRX cycle length is a value that can be specified by the Core Network (CN) domain and by the UTRAN. The CN specific DRX cycle length will be updated locally in the UE using information given in system information. For the PS CN, the value of the DRX cycle length can also be updated by negotiation between the UE and PS CN by a Non-Access Stratum (NAS) procedure. The UTRAN DRX cycle length can be specified in the CELL UPDATE CONFIRM message. The DRX cycle lengths the UE shall use is the shortest of the UTRAN DRX cycle length OR any of the stored CN domain specific DRX cycle lengths. For
Network Services
this discussion it is important to understand the impact of the DRX cycle length on the reselection measurements.
4.1.3.4.2
Timing and Filtering Requirements for Measurements and Evaluation
It is required that the UE measure the CPICH Ec/No and CPICH RSCP (of the serving cell and intrafrequency cells that are identified and measured according to the measurement rules) and evaluate the cell selection S criterion at least every DRX cycle. The UE will filter (average) these measurements using at least 2 measurements, which are taken so that the time difference between measurements is at least TmeasureFDD / 2. The averaging filter must have a maximum time constant TevaluateFDD. The specific filter implementation is vendor specific and not defined by the standards (see Table xx below). If the UE has evaluated in Nserv consecutive DRX cycles that the serving cell does not fulfill the cell selection S criterion, the UE will initiate the measurements of all neighbor cells indicated in the Measurement Control System Information broadcast on SIB11. If the UE finds no new suitable cell based on searches and measurements of neighbor cells for 12 seconds, the UE will initiate the cell selection procedures for the selected PLMN defined in the prior section. If the Treselection parameter value is set to zero and an intra-frequency cell reselection occurs, the better ranked cell is selected. If the Treselection parameter value is non-zero and the intra-frequency cell is better ranked than the serving cell, the UE will evaluate this intra-frequency cell for the Treselection time. If this cell remains better ranked within this duration, then a cell reselection of this better cell should be performed. Generally the UE will evaluate the cell reselection criteria for the cell which have new measurement results available, at least every DRX cycle. The UE shall perform cell reselection immediately after the UE has found a higher ranked suitable cell, unless less than 1 second has elapsed from the moment that the UE started camping on the serving cell. Below is a chart mapping the time requirements to DRX cycle lengths. Note that only values from 0.64 seconds and above (highlighted) are possible for idle mode. For connected mode (URA_PCH) reselection all DRX cycle values are possible. DRX cycle length [s] 0.08 0.16 0.32 0.64 1.28 2.56 5.12 Nserv [number of DRX cycles] 4 4 4 4 2 2 1 TmeasureFDD [s] (number of DRX cycles) 0.64 (8 DRX cycles) 0.64 (4) 1.28 (4) 1.28 (2) 1.28 (1) 2.56 (1) 5.12 (1) TevaluateFDD [s] (number of DRX cycles) 2.56 (32 DRX cycles) 2.56 (16) 5.12 (16) 5.12 (8) 6.4 (5) 7.68 (3) 10.24 (2) TmeasureGSM [s] (number of DRX cycles) 2.56 (32 DRX cycles) 2.56 (16) 5.12 (16) 5.12 (8) 6.4 (5) 7.68 (3) 10.24 (2)
Table 11: Time Requirements and DRX Cycle Lengths For idle mode cell reselection purposes, the UE is capable of monitoring: 32 intra-frequency cells (including serving cell) 32 inter-frequency cells including FDD cells on maximum 2 additional carriers Depending on UE capability, 32 GSM cells distributed on up to 32 GSM carriers, as indicated in cell information lists sent in system information (BCCH).
Network Services
4.1.3.4.3
Measurement Rules for Intra-frequency Cell Reselection
The recommended measure used for cell reselection is CPICH Ec/No. This is set using the parameter cellSelAndResQualMeas listed in Table 9 above. The UE measures the CPICH Ec/No at least every TmeasureFDD for intra-frequency cells that are identified and measured. For intra-frequency FDD measurements depending on the cell selection quality value Squal (Squal = Qqualmeas Qqualmin), the following rules apply: If Squal > Sintrasearch, UE need not perform intra-frequency measurements. If Squal <=Sintrasearch, UE shall perform intra-frequency measurements. If Sintrasearch is not sent in SIB of the serving cell, UE performs intra-frequency measurements. Sintrasearch is a parameter that defines a threshold for the quality value Squal above which the UE should stop performing intra-frequency measurements. This parameter is specified as sib3SIntraSearch in the Lucent UTRAN. See Table 12 for the recommended setting for this parameter. 4.1.3.4.4 Measurement Rules for Inter-frequency & Inter-RAT Cell Reselection
Similarly a criterion for inter-frequency and inter-RAT measurements is defined. If Squal > Sintersearch, UE need not perform inter-frequency measurements. If Squal <=Sintersearch, UE performs inter-frequency measurements. If Sintersearch is not sent for serving cell, perform inter-frequency measurements. The parameter Sintersearch serves the same purpose as Sintrasearch and is specified as sib3SInterSearch in the Lucent UTRAN. For inter-RAT measurements, the following criterion is defined. If Squal > SsearchRAT, UE needs not perform measurements for GSM cells If Squal <= SsearchRAT, UE shall perform measurements for GSM cells If SsearchRAT is not sent for serving cell, perform measurements for GSM cells. The parameter SsearchRAT is specified as sIB3RAT.sSearchRAT in the Lucent UTRAN. Recommended setting for these parameters can be found in Table 12. 4.1.3.4.5 Cell Reselection Criteria
The UE ranks all cells fulfilling the S criterion. This S Cell Reselection criterion for FDD and GSM cells is the same as the one used for cell selection, i.e.: UMTS FDD Cells: Squal > 0 AND Srxlev > 0 GSM Cells: Srxlev > 0 Ranking of these cells is performed using the R criteria. The cell ranking criteria R for cell reselection is defined as: For the serving cell: Rs = Qmeas,s + Qhysts
Network Services
For each neighbor cell, n: Rn = Qmeas,n Qoffsets,n TOn*(1 Ln) Measurements of the quality measure (CPICH Ec/No) is denoted here as Qmeas and used for this ranking. The quality of the serving cell is denoted with an index s and the index n is used for all measured neighbor cells. Since HCS is not used, TOn and Ln are irrelevant. Additionally, Qoffsets,n, which specifies offset between the two cells and is provided by the UTRAN in SIB11/12, is specified using the outFDDAdjCells.cellOffset parameter for UMTS Intra-frequency neighbors and outGSMAdjCells.qOffset for GSM neighbors. Thus the ranking criterion breaks down to be: Rs = Qmeas,s + Qhysts Rn = Qmeas,n Qoffsets,n The cells will be ranked according to these criteria. If a GSM cell is ranked as the best cell, then the UE shall perform cell reselections to that GSM cell. If an FDD cell is ranked as the best cell (using CPICH Ec/No as the quality measure), the UE performs a second ranking of the FDD cells according to the R criteria specified above, but using the measurement quantity CPICH Ec/No for deriving the Qmeas,n and Qmeas,s and calculating the R values of the FDD cells. The offset Qoffset2s,n is used for Qoffsets,n to calculate Rn and the hysteresis Qhyst2s is used for Qhysts to calculate Rs. Following this second ranking, the UE performs a cell reselection to the best ranked FDD cell. In all cases, the UE reselects the new cell, only if the following conditions are met: 1) The new cell is better ranked than the serving cell during a time interval Treselection. 2) More than 1 second has elapsed since the UE camped on the current serving cell. The figure 11 below illustrates the cell reselection process.
Figure 11: Cell Reselection Example

Network Services
4.1.3.4.6
Cell Reselection from GSM to UTRAN
For a multi-RAT MS, cells or frequencies on the UTRAN network may be included in the 3G Cell Reselection list (see TS 44.018 for more information on this list). The network controls the measurements for reselection of these cells by the parameter Qsearch_I broadcast on the BCCH. Qsearch_I defines a threshold and also indicates whether measurements for the UTRAN cells/frequencies will be performed when RLA_C of the serving cell is below or above the threshold. Our current recommendation is to set this parameter at 7 (which means search always). These measurements may be performed less frequently than measurements of GSM cells in order to conserve MS power. The MS can identify and select a new best UTRAN cell on a frequency, which is part of the 3G Cell Reselection list, within 30 seconds after it has been activated under the condition that there is only one UTRAN frequency in the list and under good radio conditions. The allowed time is increased by 30 seconds for each additional UTRAN frequency in the 3G Cell Reselection list. However, multiple UTRAN cells on the same frequency in the list do not increase the allowed time. A multi-RAT MS will be able to monitor 64 UTRAN cells divided into a maximum 3 FDD frequencies with a maximum 32 cells per frequency. If the 3G Cell Reselection list includes UTRAN frequencies, the MS will, at least every 5 seconds, update the value RLA_C for the serving cell and each of the at least 6 strongest non-serving GSM cells. The MS will then reselect a suitable UTRAN cell if its measured RSCP value exceeds the value of RLA_C for the serving cell and all of the suitable non-serving GSM cells by the value of FDD_Qoffset for a period of 5 seconds and the UTRAN cells measured Ec/No value is equal or greater than the value of FDD_Qmin. In case of a cell reselection occurring within the previous 15 seconds, FDD_Qoffset is increased by 5 dB. FDD_Qmin and FDD_Qoffset are broadcast on the BCCH of the serving GSM cell. As FDD_Qmin and FDD_Qoffset are parameters defined within the particular GSM network, the naming and location may vary depending on the implementation of the GSM vendor. It is important to note that the parameters required to determine if the UTRAN cell is suitable are broadcast on the BCCH of the UTRAN cell. An MS may start reselection towards the UTRAN cell before decoding the BCCH of the UTRAN cell, leading to a short interruption of service if the UTRAN cell is not suitable. Cell reselection to UTRAN will not occur within 5 seconds after the MS has reselected a GSM cell from a UTRAN cell, if a suitable GSM cell can be found. If more than one UTRAN cell fulfills the above criteria, the MS will select the cell with the greatest RSCP value.
4.1.3.4.7
Cell Reselection Parameter Settings
The values of cell reselection related parameters are presented in the table below and those parameters market with (*) also have SIB4 counterpart values which should be set if SIB4 is enabled for connected mode.
SIB Information Element
Parameter
Range
Recommendation
Description If this indicator is set to TRUE a separate set of parameters for cell selection in connected mode (URA_PCH) is broadcast using SIB4. Otherwise only SIB3 is used.
sIB3/SIB4Indicator
sIB3EnableSIB4Indicator
TRUE, FALSE
FALSE
Network Services
SIB Information Element Parameter

Range Recommendation Description Choice of measurement (CPICH Ec/No or CPICH RSCP) to use as quality measure for FDD cells. This is also sent in SIB 11/12. Both occurrences should be the same value. This parameter defines a threshold for the quality value Squal above which the UE should stop performing interfrequency FDD measurement. Recommended value of 0 dB will cause the UE to perform interfrequency measurements only when the current cell is not fulfilling the selection criterion. This parameter defines a threshold for the quality value Squal above which the UE should stop performing measurements for reselection towards GSM. The recommended value of 4 dB will cause the UE to perform interRAT measurements only when the current cell has an Ec/No value lower than -15 dB (sSearchRAT + sIB3QQualMin). Hysteresis value prioritizing the ranking of the serving cell if CPICH RSCP is used as a quality measure. Value is only applied for the hysteresis toward GSM cells if the recommended Ec/No quality measure is used for reselection between UTRAN cells. Hysteresis value prioritizing the ranking of the serving cell if CPICH Ec/No is used as a quality measure. Value is only applied for the hysteresis toward GSM cells if the recommended Ec/No quality measure is used for reselection between UTRAN cells. Time value in seconds that defines how long a neighbor cell must be ranked higher than the serving cell before this cell is selected. A longer time will make ping-pong reselections unlikely but also delay the reselection of a new cell.
SIntraSearch
sIB3SIntraSearch*
-32 - 20 [dB] 2 dB steps
10 dB
SInterSearch
sIB3SInterSearch*
-32 - 20 [dB] 2 dB steps
TBD
sSearchRAT
sIB3RAT.sSearchRAT*
-32 - 20 [dB] 2 dB steps
4 dB
Qhyst1s
sIB3Qhyst1*
0 - 40 [dB] 2 dB steps
2 dB
Qhyst2s
sIB3Qhyst2*
0 - 40 [dB] 2 dB steps
2 dB
Treselection
siB3Treselection*
0 - 31 [sec] 1 sec step
1 sec
Network Services
SIB Information Element Parameter outFDDAdjCells.cellOffset (UMTS) outGSMAdjCells.Qoffset (GSM)

Range -10 - 10 [dB] UMTS -50 - 50 [dB] GSM Recommendation Description Offsets added to the measurement quantity for the cell before the UE evaluates it for ranking of UMTS neighbor cells and GSM neighbor cells for reselection, respectively. Indicates whether inter-RAT measurements shall be performed when RLA_C of the serving cell is below or above the threshold. The thresholds are defined as: (Below) 0 = -98 dBm, 1 = -94 dBm,, 6 = -74 dBm, 7=always and (Above) 8= -78 dBm, 9 = -74 dBm,, 15 = never. Minimum Ec/No threshold for UTRAN FDD cell reselection. Settings correlate to the following Ec/No values: 0 = -20 dB, 1 = -6 dB, 2 = -18 dB, 3 = -8 dB, 4 = -16 dB, 5 = -10 dB, 6 = -14 dB, 7 = 12 dB. Applies an offset to RLA_C/P for UTRAN FDD cell reselection. Setting of 0 corresponds to always select a cell if acceptable. 1 - 15 = -28 dB to 28 dB in steps of 4 dB.
Qoffset2s,n
0 dB (UMTS) 0 dB (GSM)
Qsearch_I
0 - 15 [Integer]
FDD_Qmin
0-7 [Integer]
FDD_Qoffset
0 - 15 [Integer]
Table 12: Cell Reselection Recommended Parameters SIntraSearch If this parameter is set too small, the UE will not perform intra-frequency measurements and may miss the opportunity to perform cell reselection. If the parameter is too large, the UE will perform intra-frequency measurements although the likelihood that the neighboring cells will meet the cell reselection criteria is very small, thereby wasting idle mode current and decreasing the standby time of the UE. This parameter should be set consistently with Qqualmin since they jointly affect UE intra-frequency measurement procedures. The UE may not perform intra-frequency measurements if: CPICH Ec/No > Sintrasearch + Qqualmin = 10 dB + (-19 dB) = -9 dB SInterSearch If the parameter is too small, the UE will not perform inter-frequency measurements and may miss the opportunity to perform cell reselection to another frequency assignment. If the parameter is too large, the UE will perform inter-frequency measurements too often, most likely leading to unnecessary inter-frequency reselections, even while the current cell shows good quality, thereby decreasing standby time. Sintersearch should be chosen in accordance with Sintrasearch and Ssearch.RAT to avoid a situation where the UE performs an inter-frequency search but no intra-frequency or inter-RAT search. Preferably the values are chosen such that Sintrasearch > Sintersearch > Ssearch.RAT. SsearchRAT
Network Services
If the parameter is too small, the UE will not perform inter-RAT measurements and may miss the opportunity to perform cell reselection to another RAT. If the parameter is too large, the UE will perform inter-RAT measurements too often, most likely leading to unnecessary GSM reselections. Preferably the values are chosen such that Sintrasearch > Sintersearch > Ssearch.RAT. The UE may not perform intra-frequency measurements if: CPICH Ec/No > Ssearch.RAT + Qqualmin = 4 dB + (-19 dB) = -15 dB
Figure 12: Search Thresholds Qhyst2s Since our cell selection and reselection quality measure is based on the CPICH Ec/No, Qhsyt2s is used as the hysteresis value in the cell ranking criteria for cell reselection. If this parameter is set too small, the UE may perform frequent cell reselection to cells only marginally better than the current serving cell, which may lead to excessive battery consumption. If the parameter is set too large, the UE may be camping on a relatively weak cell although a significantly better cell is available. This particular information element can be left unspecified in SIB3. If it is unspecified, the default value is equal to Qhyst1s. It should also be set consistently with Qoffset2s since they jointly affect cell ranking. Treselection If this parameter is set too large, the UE may be camping on a relatively weak cell although a significantly better cell is available, or worse it may suffer an outage in case of a neighboring cells rising CPICH. The selected Treselection value is also applicable for inter-RAT and inter-frequency reselections. Therefore, a value larger than 0 seconds is recommended. It is recommended to use the hysteresis mechanisms instead of increasing Treselection to avoid frequent reselections. The hysteresis approach avoids delaying the selection of sharp rising pilots.
Network Services
Qoffset2s,n Since our cell selection and reselection quality measure is based on the CPICH Ec/No, Qoffset2s is used as the offset between two cells in the cell ranking criteria for cell reselection. A positive value of Qoffset deters the UE from camping on that cell. If the parameter is set too low, the UE might not be deterred enough from camping on that cell. If the parameter is set too high, the UE might never observe the criteria required to camp on that cell. If applied to all cells in the PLMN, this parameter can be used to adjust the hysteresis in 1 dB steps whereas Qhyst only allows for adjustments in 2 dB steps. Qoffset2s,n can be assigned different values for intra-frequency and inter-frequency reselection. If the neighbor cell belongs to a different PLMN or RAT or location area, Qoffset should be set to a higher value because selecting such a cell may trigger location update procedures, thereby consuming network resources, consuming idle mode current and decreasing standby time. Qsearch_I Considering only the case 0-7 (search for 3G cells if the signal level is below threshold), which is more reasonable, it the threshold is too small, the UE will not perform inter-RAT measurements and may miss the opportunity to perform cell reselection to UMTS. If it is too high, the UE will perform inter-RAT measurements often, decreasing UE standby time. This should be set in accordance with FDD_Qmin, FDD_Offset and also with intra-GSM cell reselection parameters. The parameter applies to both CS and GPRS and the corresponding parameter for GPRS is called Qsearch_P). FDD_Qmin If this parameter is too low (in dB), UTRAN FDD cells may undergo cell reselection too frequently. If the parameter is too high (in dB), UTRAN FDD cells may not be reselected. FDD_Qoffset If this parameter is too high, UTRAN FDD cells may not be reselected. If a cell reselection has occurred within the previous 15 seconds, FDD_Qoffset is increased by 5 dB. The parameter applies to both CS and GPRS and the corresponding parameter for GPRS is called FDD_GPRS_Offset).
4.1.3.4.8
Impact on Related Performance Measurements
As cell reselection is a pure UE procedure, there are no performance measurements (PMs) directly related. The reselection behavior of the UE can only be investigated using test equipment. However, the reselection behavior of the UE indirectly influences the network quality. Wrong cell reselection may lead to RACH accesses on cells not offering the best radio conditions for the UE. If the reselection procedure frequently triggers the reselection of a new cell this will also increase the number of LA/RA/URA updates at the borders of location areas. Therefore, an increase of location updates will be visible if the UE exhibit a more frequent cell reselection. However, this influence may be hard to reveal taking the high statistical fluctuations into account. The performance measurement NumCellUpdReq.CellReselect is a counter for the performed cell updates with the cause Cell Reselection. The counter NumUraUpdateRequest.UraChange gives the number of URA updates performed in this cell. Other counters for location updates may be available from the core network. Assuming a constant number of subscribers populating similar areas of the network, these measurements can reflect the number of cell reselections performed by the UEs in this cell. Note that there are other counters measuring the number of cell updates due to other reasons than cell reselection (e.g. paging response, UL data, RLC error, radio link failure, re-entering service area, etc.).
Network Services
4.1.4
Paging in Idle Mode
The Paging Channel (PCH), a downlink transport channel, is always transmitted over the entire cell. The transmission of the PCH is associated with the transmission of physical layer generated Paging Indicators (PI), to support efficient sleep mode procedures. These sleep mode procedures are defined by Discontinuous Reception (DRX) which was discussed earlier.
4.1.4.1
Discontinuous Reception for Paging
The UE uses Discontinuous Reception (DRX) in idle mode in order reduce power consumption (introduced earlier in Table 11: Time Requirements and DRX Cycle Lengths). When DRX is used the UE needs only to monitor one Page Indicator in one Paging Occasion per DRX cycle. The DRX cycle length in milliseconds is defined as 10 * max (2k, 1) frames, where k is an integer and 1 represents the Paging Block Periodicity (this can be a different value for TDD operation). The UE can attach to different CN domains with different CN domain specific DRX cycle lengths. The UE stores each CN DRX cycle length for each CN domain that the UE is attached and uses the shortest of those DRX cycle lengths. The CS CN specific DRX cycle length coefficient will be updated locally in the UE using system information. However, the PS CN specific DRX cycle length coefficient will be updated after the negotiation between the UE and PS CN by NAS procedures. If no specific value k is negotiated in the NAS procedures, the UE and PS CN shall use the DRX cycle length given for the PS CN domain in system information. The DRX cycle lengths to use for UTRAN connected mode is the shortest of the following: UTRAN DRX cycle length Any of the stored CN domain specific DRX cycle lengths The UE will use the IMSI, the number of available SCCPCH which carry a PCH (K), the Cell System Frame Number (SFN), Np (the number of page indicators with a frame), Frame offset (0 for FDD), PBP (1 for FDD), and DRX cycle length to determine the Paging Occasions. The UE will monitor its paging indicator in the PICH frame with SFN by the Paging Occasion. The value of the Paging Occasion is determined as follows: Paging Occasion = {(IMSI div K) mod (DRX cycle length div PBP)} * PBP + n *DRX cycle Length + Frame Offset = {(IMSI div K) mod(DRX cycle length)} + n* DRX cycle length where n = 0, 1, 2. as long as SFN is below its maximum value. The actual Page Indicator within a Paging Occasion that the UE will read is similarly determined based on the IMSI. The Page Indicator to use is calculated using the following formula: PI = DRX Index mod Np where DRX Index = IMSI div 8192
Np = (18, 36, 72,144) is the number of Page Indicators per frame and provided as part of the system information.
Network Services
4.1.4.2 Paging Channel Selection System information block type 5 (SIB5) defines common channels to be employed in idle mode. In a cell, a single or several PCHs may be established. Each Secondary Common Control Physical Channel (SCCPCH) indicated to the UE in system information may carry up to one PCH. Thus, for each defined PCH there is one uniquely associated PICH also indicated. In case that more than a single PCH and associated PICH are defined in SIB5, the UE shall perform a selection according to the following rule: The UE shall select a SCCPCH from the ones listed in SIB5 based on IMSI as follows: Index of selected SCCPCH = IMSI mod K, where K is equal to the number of listed SCCPCHs which carry a PCH (i.e. SCCPCHs carrying FACH only will not be counted). These SCCPCHs are indexed in the order of their occurrence in SIB5 from 0 to K-1. Index of selected SCCPCH identifies the selected SCCPCH with the PCH and the uniquely associated PICH to be used by the UE. The Paging Indicator Channel (PICH) is a fixed rate (SF=256) physical channel used to carry the paging indicators. The PICH is always associated with a SCCPCH to which a PCH transport channel is mapped. Illustrate below is the frame structure of the PICH. One PICH radio frame of length 10 ms consists of 300 bits. Of these, 288 bits are used to carry paging indicators. The remaining 12 bits are not formally part of the PICH and will not be transmitted (DTX).
Figure 13: Structure of Paging Indicator Channel (PICH) Figure 13 illustrates the timing between a PICH frame and its associated single S-CCPCH frame, i.e. the SCCPCH frame that carries the paging information related to the paging indicators in the PICH frame. A paging indicator set to 1 in a PICH frame means that the paging message is transmitted on the PCH in the S-CCPCH frame starting 7680 chips (3 slots) after the transmitted PICH frame. For detection of the PICH,
Network Services
the terminal needs to obtain the phase reference from the CPICH, and as with the AICH, the PICH needs to be heard by all terminals in the cell and thus needs to be sent at a high power level without power control. The less often the PIs appear, the less often the UE needs to wake up from the sleep mode (determined by the DRX cycle) and the longer the battery life becomes. The trade-off is obviously the response time to a network originated call.
Figure 14: Timing Relation Between PICH frame and associated S-CCPCH frame 4.1.4.3 Paging Procedures
Paging procedure is used to transmit paging information to selected UEs in idle mode, CELL_PCH, or URA_PCH state using the paging control channel (PCCH). Upper layers in the network may request paging in order to perform task such as establishing a signaling connection. The UTRAN may initiate paging for UEs in CELL_PCH or URA_PCH state to trigger a cell update procedure. In addition, the UTRAN may initiate paging for UEs in idle mode, CELL_PCH, and URA_PCH state to trigger reading of updated system information. The UTRAN initiates the paging procedure by transmitting a PAGING TYPE 1 message on an appropriate paging occasion on the PCCH. UE dedicated paging procedure is used to transmit dedicated paging information to one UE in connected mode in CELL_DCH or CELL_FACH state. Upper layers in the network may request initiation of paging. FOR a UE in CELL_DCH or CELL_FACH state, the UTRAN initiates the procedure by transmitting a PAGING TYPE 2 message on the DCCH.
4.1.4.4
Paging Parameters in Idle Mode
The values of idle mode paging related parameters are presented in the table below.
Network Services
SIB Information Element CN DRX Cycle Length Coefficient
Parameter cnCsDrxCoefficient cnPsDrxCoefficient
Range 3 to 9 (2^value * 10 ms)
Recommendation
7 (1.28 s)
Description Periodicity of the paging occasion corresponding to a given UE in idle mode Periodicity of the paging occasion corresponding to a given UE in connected mode (CELL_PCH and URA_PCH mode) Power level of the Paging Indicator Channel. This power is set a a relative power in relation to the PCPICH The maximum number of paging indicators that are transmitted in each Paging Indicator Channel (PICH) frame.
UTRAN DRX Cycle Length Coefficient
uTRANDRXCycleCoefficient
3 to 9 (2^value * 10 ms)
6 (0.64 s)
PICH Power Offset
pICHPower
-10 to 5 [dB]
-6 dB
Number of PI per frame (Np)
pICHMode
18, 36, 72, 144
18
Table 13: Paging Parameters cnCsDrxCoefficient, cnPsDrxCoefficient If this parameter is set too low, the UE standby time decreases. If set too high, the UE-terminated callsetup latency increases and the delay cell reselection process might cause reduced access performance. Separate CN DRX Cycle Length Coefficients can be defined for the CS domain and for the PS domain. If the values differ, the UE will use the shorter of the two cycle lengths. Since the current drawn by the UE in idle mode when the UE is demodulating the PICH is much larger than the current drawn when asleep, the standby time nearly doubles with every doubling of the DRX cycle length. The delay induced by queuing the paging message also doubles with doubling the DRX cycle length. However, the overall call setup delay increases only marginally with increasing DRX cycle length, provided that the paging queuing delay is small relative to other delays. This parameter value is also included in the following RRC messages: CELL UPDATE CONFIRM PHYSICAL CHANNEL RECONFIGURATION RADIO BEARER RELEASE RADIO BEARER SETUP TRANSPORT CHANNEL RECONFIGURATION URA UPDATE CONFIRM uTRANDRXCycleCoefficient If this parameter is set too low, the UE standby time decreases. If set too high, the time delay for a transition from CELL_PCH state or URA PCH state to the CELL_FACH state increases. Similar notes apply as for the CN DRX Cycle Length Coefficient above. However, the tradeoff for the UTRAN DRX Cycle Length Coefficient can favor a shorter cycle length. Typically, a UE is in CELL_PCH or URA_PCH state for a shorter overall duration than in Idle Mode, resulting in smaller power savings. In addition, the transitions to the CELL_FACH mode typically occur with higher frequency than Idle Mode to Connected Mode transitions, thus a shorter call reactivation period is preferred. This parameter is included in the same RRC messages mentioned above for the CN DRX Cycle Length Coefficient.
Network Services
pICHPower This parameter sets the PICH transmit power relative to the P-CPICH power. If it is set too low, the probability of miss detection and probability of false alarm increases. If this is set too high, the downlink capacity is wasted. It is important to note that the required offset increases by 3 dB with the doubling of the number of paging indicators per frame (Np). This parameter is found in SIB5/SIB6. Assume, for example, a target value of 10 dB for the minimum received signal-to-noise ratio of the PICH. This corresponds to a miss-detection probability of ~1% in a single path Rayleigh fading channel. Further, assume that the cell loading is such that the CPICH Ec/Ior = -10 dB and that the number of paging indicators per frame is 18. For a PICH power offset of -6 dB, the target signal-to-noise ratio is always exceeded provided the CPICH Ec/No is not less than -17.5 dB. In a typical cell 95% of the cell area experiences a CPICH Ec/No of -17.5 dB or better. Therefore, 95% of the UEs will experience a miss-detection probability of 1% or less (see graphs below).
Figure 15: PICH Indicator Probability of Misdetection
Figure 16: PICH Required Offset (Np=18)
Network Services
pICHMode The parameter represents the number of paging indicators (PI) per frame and, consequently, the number of PICH bits that are mapped to a single PI. If this parameter is set too high, a disproportionate amount of power must be reserved for PICH operation (i.e. affects setting for pICHPower), thereby decreasing the downlink capacity. So that means that if pICHMode is increase, pICHPower should be increased proportionally (remember doubling corresponds to a 3 dB increase). A larger value of pICHMode has the advantage of decreasing the PICH collision probability. A collision is defined as the event when a UE which is not being paged wakes up because its assigned PI is shared with another UE which is being paged in the current paging occasion. The collision probability is sufficiently low even when pICHMode is set to its minimum value of 18.
4.2
Random Access and Call Establishment
This section will discuss the procedures and algorithms involved in UE initial access on the UTRAN system. For an UE initiated connection, the UE will first go through a random access procedure to get system resources in order to trigger other functions such as load control (admission control and congestion control). Access control and initial assignment is the process of gaining the attention of the system, obtaining authorization to use system services, and the initial assignment to a communication channel in order to set up either a voice or a data session. Access control and initial assignment occurs when a mobile device responds to a page (incoming connection request), desires to set up a call, or any connection attempt by the mobile device. Access to the UMTS system is a random occurrence and not usually pre-planned.
4.2.1
RRC States
In order to understand connected mode functions, it is important to understand the RRC Service States. The figure below shows the main RRC service stated in the connected mode.
Figure 17: UE Modes and RRC States in Connected Mode The RRC has two modes of operation: idle mode and connected mode. In idle mode, no signaling connection exists between the UE and the UTRAN. When the UE is in connected mode, user data may be
Network Services
transferred between the UE and the UTRAN. The idle mode processes have been described in the previous section but lets review the four reasons for a UE to camp on a cell. It enables the UE to receive system information from the PLMN The process of initiating a call is simpler as the UE has already chosen a cell The UE is ready to accept incoming calls and the UE will be notified of an incoming call via the control channel to which the UE continues to listen While idle, the UE is able to conserve battery consumption by sleeping and only waking up periodically to check for incoming messages. The UE stays in idle mode until it transmits a request to establish an RRC connection. This places the UE in connected mode. In this mode, one and only on signaling connection exists between the UE and the Radio Network Controller (RNC) the RRC connection. In this mode, the UE is assigned a Radio Network Temporary Identity (RNTI), which is used to identify the UE on common transport channels. In addition, the UE is known at either the cell level or the UTRAN Registration Area (URA) level (i.e. a set of cells). Depending on the state of the UE connection, different mechanisms are used to communicate with the UE. The UE may or may not have dedicated resources depending on the state of the mobile. Below is a brief description of the connected mode states. CELL_DCH In this state, the UE is assigned dedicated resources and can send data in the uplink and downlink. Mobility is managed by the UTRAN via the soft handover (SHO) procedure and location is known at the cell level. The UE also performs measurements and sends measurement reports according to measurement control information received from the RNC. CELL_FACH In this state, no dedicated physical channel is allocated for the UE, but RACH and FACH channels are used instead, for transmitting both signaling messages and short data transfers such as SMS. The UE is also capable of listening to the broadcast channel to acquire system information. In this state the UE performs cell reselections and after a reselection always sends a Cell Update message to the RNC, so that the RNC knows the UE location on the cell level. CELL_PCH While in this state, the UE cannot send uplink or downlink data and the UE is monitoring the paging channel (PCH) for network initiated operations. In this state the UE battery consumption is less than in the CELL_FACH state, since the monitoring of the paging channel includes discontinuous reception (DRX) functionality. The UE also listens to system information on the BCH. If the UE performs a cell reselection, it moves autonomously to the CELL_FACH state to execute the Cell Update procedure, after which it re-enters either the CELL_PCH or URA_PCH state if no other activity is triggered during the Cell Update procedure. If a new cell is selected from another radio access technology (like GSM), the UTRAN state is changed to idle mode and access to the other system is performed according Inter-RAT specifications. This state is not optimal for users that have a high level of mobility. URA_PCH Like Cell_PCH, the UE cannot send data and is monitoring the PCH. However, in this state, mobility is tracked at the UTRAN Registration Area (URA), which is a collection of cells. The UE does not execute Cell Updates after each cell reselection, but instead reads URA identities from the broadcast channel and only if the URA changes (after cell reselection), does the UE inform its location to the Serving RNC (SRNC). This is performed via the URA Update procedure that is similar to the Cell Update procedure (the UE enters the CELL_FACH state to execute the procedure and then reverts back to the URA_PCH state). This state is preferred for users that have a high frequency of cell reselections. The UE leaves the connected mode and returns to the idle mode when the RRC connection is released or at RRC connection failure.
Network Services
4.2.2
RACH Access Procedure
The RACH is an uplink transport channel that is used by the UEs to gain initial access to the network, to respond to paging, to set up a data call, or to perform UTRAN location updates. These are the main functions of the RACH in Lucents current software release. In future releases, the RACH will also be used to send data and other signaling messages. In general, the RACH access procedure is based on a slotted ALOHA approach with fast acquisition indication. This means that the UE can start the transmission on the RACH at the beginning of a number of well-defined intervals, denoted as access slots. There are 15 slots per two frames and they are spaced 5120 chips apart as depicted in the figure below.
Figure 18: RACH Access Slot Format The RACH procedure consists of 3 phases: 1) RACH Preamble Part: Preamble Initial Power is determined by Open Loop Power Control 2) Power Ramping Cycle: The UE sends one or several RACH Preamble Parts and awaits Acknowledge message (ACK) on the AICH from the Node B 3) RACH Message Part: The UE sends the RACH Message Part
Network Services
Figure 19: RACH Preamble Part, Power Ramping Cycle, and RACH Message Part Several RACH Preamble Parts group to form a Power Ramping Cycle. It may be necessary to perform several Power Ramping Cycles until the UE receives an ACK from the Node B on the Acquisition Indication Channel (AICH). The maximum number of cycles is defined by the parameter mMax. If the UE has received one Negative ACK (NACK) message from the Node B on the AICH, the UE has to stop sending further RACH Preamble Parts. If the maximum number of allowed power ramping cycles has not been reached, the MAC layer will start a new power ramping cycle after waiting some time interval. The RACH is a contention-based channel in which many users attempt to use the same channel resources. Because users that want to gain access to the RACH do not have any knowledge of when other users will try to access the RACH, the access attempts may result in collisions (users attempting to use the same channel resources at the same time) that cause loss of data and result in unsuccessful accesses. After the UE has successfully gained access to the RACH, the user is able, for example, to request data services. To reduce the collision probability, several layers of randomization have been implemented. The main aim of optimizing the RACH parameters is to improve the success rate of the RACH, i.e. to increase the rate at which uncorrupted data arrives at the Node B. In order to achieve this, the number of collisions must be minimized. Another optimization approach is to minimize the delay in accessing the RACH. In addition, the interference generated on the UL by the RACH procedure should also be minimized by using the RACH Overload Control Algorithm.
4.2.2.1
Phase 1: RACH Preamble Part
The RACH is an UL transport channel that is mapped to a physical channel called the Physical Random Access Channel (PRACH). The Physical Layer controls the transmission of the RACH Preamble Parts within one Power Ramping Cycle. It also determines, with the help of Open Loop Power Control Algorithm, the power of the RACH Preamble Parts and is responsible for the timing of sending the RACH Preamble Parts.
Network Services
4.2.2.1.1
RACH Structure
The RACH is transmitted on the Physical Layer in two separate parts. First, a certain number of RACH Preambles are sent. The power of the first RACH Preamble is relatively low and calculated using Open Loop Power Control. Each of the following RACH Preambles are transmitted with increasing power until the UE has received and ACK, NACK, or after sending the RACH Preambles MaxRetranPreamble times. In the case where an ACK is received, the UE transmits the RACH Message Part where the RRC Connection Request message is embedded. Each RACH Preamble is of length 4096 chips and it is transmitted using a RACH Preamble Scrambling Code within the 5120-chip access slot. This scrambling code consists of 256 repetitions of a RACH Preamble signature of length 16 chips. RACH Preamble Scrambling Code In the current (P1 Lite) Lucent software release, it is possible to configure only one RACH Preamble Scrambling Code (SC) per cell whereas in later releases up to 16 RACH Preamble SCs will be available per cell. There are 8192 PRACH preamble scrambling codes divided into 512 groups with 16 codes in each group. There is a one-to-one correspondence between the group of PRACH preamble scrambling codes in a cell and the primary scrambling code used in the downlink of the cell. Sr-pre,n is the name of the nth SC of the RACH Preamble determined by the following formula: n = 16*m + k In this formula m is the DL Primary SC of the cell (where m = 0, , 511) and k=0,1,2,,15. Before the UE starts a new Power Ramping Cycle, the UE receives at the Physical Layer from the RRC layer the RACH Preamble SC to use. However, the RACH Preamble SC remains the same for all the power ramping cycles within each MAC layer procedure. RACH Preamble Signature The RACH Preamble Signatures are another possibility of separation to send the RACH Preamble. They are repeated 256 times and their length is equal to 16 chips. There are up to 16 different RACH Preamble Signatures available in each cell. Each time the UE is sending a RACH Preamble, the UE will randomly select a RACH Preamble Signature (from the available set) thus each RACH Preamble Signature has an equal probability of being selected. The signatures are derived from the set of 16 Hadamard codes of length 16. It is important to not that by using different RACH Preamble Signatures will result in also using different channelization codes for the control and data part of the RACH Message Part. RACH Preamble Sub-Channel A RACH Preamble Sub-Channel defines a subset of the total set of uplink access slots. There are a total maximal 12 RACH sub-channels in each cell available. The figure below illustrates the relation of Access Slots and the RACH Preamble Sub-Channel. The colored boxes show for each RACH Preamble SubChannel the available access slot. As an example, for RACH Preamble Sub-Channel 0, there is in the first frame Access Slot 0 available for sending the RACH Preamble, in the second frame Access Slot 12, in the third frame Access Slot 9, etc.
Network Services
Figure 20: Relationship Between Sub-Channel Number and Access Slot The available sub-channels are made known to the Physical Layer from the RRC Layer. The UE then derives the access slots that it can use. From the available access slots, the UE chooses randomly an access slot for the first RACH Preamble. For the following RACH Preambles (i.e. not the first one), the UE will see which access slots are available next and this will depend on the minimum preamble-to-preamble distance (see discussion on preamble timing in the Phase 2 section). In general, once the RACH Preamble is sent with a certain calculated power, the UE will wait for an ACK message from the NodeB on the AICH. If there is no response, the UE will select randomly a new signature (maybe even the same one), increase the power, and send the RACH Preamble again on the next available access slot.
4.2.2.1.2
Initial Preamble Power
The Open Loop Power Control Algorithm located in the UE is used to determine the Initial Preamble Power. Prior to the transmission of the RACH Preamble Part, the Initial Preamble Power is calculated using the following formula: Preamble_Initial_Power [dBm] = Primary CPICH TX Power CPICH RSCP + UL Interference + Constant Value where: Primary CPICH TX Power is the transmit power of the P-CPICH CPICH RSCP is the Received Signal Code Power measured by the UE UL Interference corresponds to the Received Signal Strength Indicator (RSSI) measurements at the Node B. Constant Value [dB] is an additional term defined by a UTRAN parameter that gives the target SIR that the UE should try to achieve on the RACH.
Network Services
The difference between the Primary CPICH TX power and the CPICH RSCP gives the path loss estimation. Both Primary CPICH TX power and UL Interference are read by the UE from SIB messages sent on the BCH.
4.2.2.1.3
Phase 1 Parameter Settings
The parameters associated with this Phase of the Random Access Procedure are presented in the table below. It should be noted that the parameter primaryScramblingCode is the defined DL Primary Scrambling Code and corresponds to the value m listed in the formula above for the RACH Preamble Scrambling Code. It is an integer between 0 and 511 and its value is computed during the cell planning process.
Parent Object
Parameter Name
Recommended Setting
Range 0 to 65535 [Integer]
PRACH
preambleSignature
1111111111111111 [65535]
PRACH
subChannelNumbers
111111111111 [4095]
0 to 4095 [Integer]
PRACH
constantVal
-27 dB
-35 to -10 [dB]
Short Description The largest number of signatures should be used in order to decrease the probability of collisions. In P1Lite, this is important because only one RACH Preamble Scrambling Code is available per cell. The largest number of signatures should be used in order to decrease the probability of collisions. In P1Lite, this is important because only one RACH Preamble Scrambling Code is available per cell. Too low values may cause RACH Preambles to be detected at very low Eb/No. Otherwise, with too high values, RACH preambles may be transmitted with more power than is necessary to be detected, thus increasing uplink interference. Its setting also affects the calculation of the RACH Message Part power, thus its value has to be considered along with setting of parameters gainFactorBc and PowerOffsetPpm
Table 14: Parameter Settings for Phase 1 RACH Preamble Part preambleSignature The parameter preambleSignature defines the availability of different RACH Preamble Signatures in one cell. It is an integer between 0 and 65535. In binary format, each bit of preambleSignature indicates the availability of a RACH Preamble Signature, e.g. 1 indicates that the corresponding signature is available while 0 indicates that it is not: Bit 1: Signature number 0 Bit 2: Signature number 1 .. Bit 16: Signature number 15
Network Services
subChannelNumbers The parameter subChannelNumbers determines the availability of different RACH Preamble Sub-Channels in a cell. It is an integer between 0 and 4095. In binary format, each bit of subChannelNumbers indicates the availability for a RACH Preamble Sub-Channel, e.g. 1 indicates that the corresponding RACH Preamble Sub-Channel is available, while 0 indicates that it is not: Bit 1: Preamble Sub-Channel 0 Bit 2: Preamble Sub-Channel 1 .. Bit 16: Preamble Sub-Channel 15 During the RACH Preamble transmission, collisions will occur when two users are selecting the same RACH Preamble SC, RACH Preamble Signature, and RACH Access slot. For this reason, the largest number of signatures as well as of RACH Preamble Sub-Channels should be used. If either the number of signatures or the number of RACH Preamble Sub-Channels is reduced, this increases the probability of collisions. This is especially important in Lucents current software release (P1 Lite/ 03.01) since only one RACH Preamble SC is available per cell. constantVal This constant is used to determine the initial PRACH transmitted power. If this is set too small, the preamble initial transmit power may be insufficient for reliable detection at the Node B. This leads to a delay in the access procedure since a longer sequence of power ramping preambles is required. If this is set too large, the preamble initial transmit power may be larger than needed for reliable detection at the Node B. This causes unnecessary uplink interference. This constantVal is provided in the PRACH system information list in SIB5/SIB6. This parameter also affects the setting of the Power Offset Pp-m parameter. If one analyzes the equation for setting the preamble initial power above, one finds that the constantVal represents the RACH preamble received Ec/No. Therefore, the constantVal parameter should be set to the preamble target Ec/No. To allow for occasional decorrelation between the downlink and uplink, it is appropriate (in terms of avoiding excess UL interference) to set constantVal 2-3 dB lower than the nominal required RACH detector Ec/No. The preamble duration is 4096 chips corresponding to a processing gain of ~36 dB. When using an energy detector with coherent integration time equal to 4096 chips to detect the preamble at the Node B, the detection threshold that achieves sufficiently low probability of false alarm (~ 1 false alarm per second) is Ec/No =-25 dB. Assuming that the Node B employs such thresholds and dual receive antennas, then the required preamble received Ec/No to achieve a probability of detection of 50% or better in an AWGN channel is -26 dB or -19.5 dB for 0 km/h and 150 km/h, respectively.
4.2.2.2
Phase 2: Power Ramping Cycle
After the initial power for the preamble is determined, the UE sends one or several Preamble Parts grouped in a Power Ramping Cycle. It may be necessary to perform several of these Power Ramping Cycles until the UE receives an ACK from the Node B on the AICH. The MAC layer is responsible for controlling the start of new power cycles (initially or in case of reception of a NACK). These cycles begin with understanding how each successive preambles power is incremented.
4.2.2.2.1
Successive Preamble Power
When no ACK message is received from the Node B following the transmission of the first RACH preamble, the power of the next RACH preamble within the same power ramping cycle is increased and calculated by the following formula:
Network Services
Next_preamble_power [dBm] = Previous_preamble_power + PowerRampStep where: Previous_preamble_power is the transmitted power on the previous RACH preamble within the same power ramping cycle PowerRampStep defines the power step increase Within one power ramping cycle the UE will retransmit the RACH preamble, each time increasing the power according to the above formula, until the reception of an ACK or NACK or until the maximum number of repetitions defined by the parameter MaxRetranPreamble is reached. It is important to note that the maximum power for the RACH Preamble is only limited by UE capabilities. There is also a parameter which sets the detection threshold of the RACH Preamble detector at the Node B. This preamble detector uses the threshold to identify incoming RACH preambles. The ratio between the received preamble power during the preamble period and interference level must be above this threshold in order for the RACH preamble to be detected and acknowledged. The figure below depicts the power ramping cycle procedure.
Figure 21: Power Ramping Cycle Illustration 4.2.2.2.2 Power Ramping Cycle Algorithm
The MAC layer controls the timing when to start a new Power Ramping Cycle. After a certain number of Power Ramping Cycles have been unsuccessful, the MAC will not start with a new Power Ramping Cycle until it receives a message command to begin with new Power Ramping Cycles. In general, there are 4 cases (1 successful and 3 unsuccessful) that have to be distinguished.
Case 1: Node B Sends Back ACK on the AICH
Network Services
If the Node B detects the RACH Preamble Part and there are enough resources to process the RACH Message Part, the Node B will send an ACK on the AICH. After the UE has received the ACK, the UE will stop sending further RACH Preamble Parts. After a time called preamble-to-message distance, the UE will send the RACH Message Part. The time preamble-to-message distance depends on the settings of the parameter aICHTransmissionTiming. This parameter basically determines the preamble-toacknowledgement, preamble-to-message, and minimum preamble-to-preamble distance. The two figures below illustrate the impact on timing for the two allowed settings (0 or 1) for this parameter.
Figure 22: Timing Relation for aICHTransmissionTiming =0
Figure 23: Timing Relation for aICHTransmissionTiming = 1 This parameter does not have a great influence on the RACH performance because the only difference between the two settings is that the minimum distance between the messages and between the preambles is increased by one slot (1.33 ms). Case 2: No detection of RACH Preamble If one Preamble Power Ramping Cycle has been performed and there was no ACK (or NACK) sent back by the Node B on the AICH (see figure below), the UE will wait for a time called Persistency Delay (equal to 10 ms) before starting the next Power Ramping Cycle. Furthermore, before starting the next Power Ramping Cycle, the UE has to perform a persistency check based on load information sent by the RNC on SIB. If the UE persistency check fails, then it waits another 10 ms (persistency delay) before trying another persistency check. This may be the case when the Node B has not detected the RACH Preamble.
Network Services
Figure 24: Successful and Unsuccessful RACH Procedures Case 3: Node B sends back NACK on the AICH If the Node B detects the RACH Preamble, but does not have enough resources to process the ensuing RACH Message Part, the Node B will send a negative acknowledgement (NACK) on AICH. The UE then waits for a period of time given by Persistency Delay plus Back-Off Period before performing the Preamble Power Ramping Cycle again. The Back-Off Period is a time interval that is randomly determined by the UE. This Back-off timer is used because it is likely that other UEs have also received NACKs during the same radio frame. So those UEs may also retry sending RACH Preambles and therefore repeat to use the free resources with their RACH Message Parts. Case 4: Number of Power Ramping Cycles Exceeded If the number of Power Ramping Cycles that the UE has performed reaches the maximum allowed number (based on the parameter setting) without getting back an ACK/NACK message by the Node B on the AICH, the MAC Layer procedure is considered to be failed. It is up to the higher layer (e.g. RRC for RRC Connection Setup, URA Updated Procedure, or in later releases RLC for sending small amounts of data) to start with the new Power Ramping Cycles again. In this case, the failure is notified to the RRC layer that will resend the message according to the rules. The following flow chart illustrates the MAC procedures associated with controlling RACH transmissions.
Network Services
Start
Get RACH TX control Parameters from RRC
No
Any Data to TX on RACH?
Yes ASC Selection (PRACH probability Pi)
Initialize preamble TX counter M=0
Case 4
Increment Preamble TX Counter M
M <= M max? Yes Update RACH TX control parameters
No
Indicate to higher layer Mmax reached (TX status unsuccessful)
End
Wait for Expiry of Backoff timer
Persistency Delay = 10 ms
Wait for Expiry of Persistency Delay
Draw Random Number 0<=R<=1
Set Back-off timer to NB01*10ms where NB01min <=NB01 <=N B01max
No R <= Pi?
Yes Physical Layer Preamble Power Ramping Cycle
RRC Layer Persistency Check
No
Received Acknowledgement
Yes
No (NACK) ACK?
Case 2
Case 1
Yes TX RACH Message Part
Case 3
Figure 25: Flow Chart for RACH Procedures
Network Services
4.2.2.2.3
Phase 2 Parameter Settings
The parameters associated with this Phase of the Random Access Procedure are presented in the table below. Parent Object PRACH Recommended Setting
Parameter Name PowerRampStep
Range 1 - 8 [dB]
2 dB
PRACH
maxRetranPreamble
15
1 to 64
LCell
sIB3MaxAllowedULTxPower
24 dBm
-35 to -10 [dB]
Short Description UE transmit power increase between subsequent transmissions on the RACH when no acquisition indicator is received Maximum number of preamble transmissions in one preamble ramping cycle This parameter defined the maximum UE TX power (based upon the power class supported by the network). This parameter is used by the UE to determine the preamble-toacknowledgement, preamble-tomessage, and minimum preamble-to-preamble distance. This parameter defines the maximum number of preamble ramping cycles. Minimum random back-off time in case of receipt of a negative acknowledgement (NACK) on the AICH. Maximum random back-off time in case of receipt of a negative acknowledgement (NACK) on the AICH. This threshold is used by the NodeB as a minimum threshold for detecting RACH preambles.
PRACH
aICHTransmissionTiming
att-0
att-0, att-1
PRACH
mMax
1 to 32 0 - 50 ms 10 ms steps 0 - 50 ms 10 ms steps -36.0 0 dB 0.5 dB steps
PRACH
nB01min
0 ms
PRACH
nB01max
50 ms
PRACH
physicalRACHPreambleThreshold
-23 dB
Figure 26: Parameter Settings for Phase 2 Power Ramping Cycle PowerRampStep This parameter setting depends on the settings of MaxRetranPreamble and preamble Threshold as the best trade off between minimizing UL interference and speed up the successful UE access to the network. If the parameter is too small, the number of RACH preambles and the access latency increases. If the parameter is too large, the uplink interference increases. This parameter should be set relatively small if maxRetranPreamble is set to a relatively large value, and vice versa, as their effect on latency and uplink interference is compounded. maxRetranPreamble This parameter setting depends on the previous parameter, PowerRampStep. Very high values will cause increased UL interference in the system by allowing UEs to transmit a large number of RACH Preambles as well as increase the RACH access delay. Very low values may result in the RACH Preambles never
Network Services
reaching the power required to be acknowledged (assuming that powerRampStep is also set at a low value). This is especially the case if the preamble Threshold is set to a high value. This tradeoff is illustrated below.
Figure 27: Parameter Relationship for powerRampStep & maxRetranPreamble aICHTransmissionTiming This parameter sets the time interval between the UL access preamble and the corresponding DL access indicator and consequently, the interval between two successive access preambles and the interval between the last access preamble and the access message. The setting is dictated by UTRAN implementation constraints (the turn-around time from preamble detection to AICH indicator transmission. A parameter setting of 0 indicates a 3 access slot minimum distance for preamble-to-preamble and preamble-to-message. It also equates to a 7680 chip distance between a preamble and associated acquisition indicator. mMax High values of this parameter increase the delay of the RACH procedure, particularly if the first few Preamble Power Ramping Cycles are not successful in obtaining ACK from the Node B. However, in case of heavy load on the RACH and lack of resources in the Node B, multiple NACKs will be sent to the UE. Therefore, for heavy load scenarios, it may be advantageous to set this parameter to 5. On the other hand, for lightly loaded scenarios, it is recommended to set this parameter to 2. nB01min The minimum setting of the Back-off Timer has to be considered along with the setting of the parameter nB01max. Both parameters may be set equal when a fixed Back-off delay is desired, and even to zero when no delay other than the one due to persistency is desired. Information on persistency is covered in the section regarding RACH Overload. nB01max
Network Services
If this parameter is set to a value larger than 10 ms, the UE will have to wait at least 30 ms after receiving a NACK (at least 20 ms for back-off plus 10 ms for T2 timer expiration) before the next preamble transmission can be started. The T2 timer ensures that two successive persistency checks are separated by at least one 10 ms interval (for more information see TS 25.321 section 11.2.2.). physicalRACHPreambleThreshold The ratio between the received preamble power during the preamble period and the interference level must be above this threshold in order for the preamble to be acknowledged.
4.2.2.3
Phase 3: RACH Message Part
After the RACH has been acknowledged via the AICH and after waiting a certain time defined as preambleto-message distance, the UE sends the RACH Message Part. In Lucents current software load (03.01), the RACH Message Part is used to carry the RRC Connection Request, the Cell Update, or the URA Update message. Each slot consists of a PRACH data part to which the RACH transport channel is mapped and a PRACH control part that carries Physical layer control information. The data and control parts are transmitted in parallel multiplexed as I/Q branch.
4.2.2.3.1
RACH Message Part length (TTI)
The RACH Message Part may have a length of 10 ms or 20 ms (TTI 10 ms and TTI 20 ms). SIB 5 and SIB 6 indicate the TTI available for the RACH. This information is embedded in the RACH Transport Format Set. The UE chooses a proper TTI for the RACH Message Part from the RACHs included in the list of candidate PRACHs according to the following process. 1) If only RACHs with one particular TTI are included in the list of candidate PRACHs, select this TTI length. 2) If both PRACHs with 10 ms and 20 ms TTI lengths are included in the list of candidate PRACHs, select a Transport Format (TF) to be employed for calculation of a transmit power margin when calculating the initial preamble transmit power (as defined in section 4.2.2.1.2). o From the TFs supported by all candidate PRACHs, keep those which correspond to a single transport block or all configured RLC sizes. If more than a single TF is available, the UE may select any of these. Preferably, the UE will select the TF which is intended to be used on the next transmission or the TF corresponding to the largest configured RLC size
3) Next the transmit power margin must be calculated. The formula for calculating the margin is given below: Margin = {min(Maximum Allowed UL TX Power, P_MAX) max(Preamble_Initial_Power, Preamble_Intial_Power + Pp-m + 10*log10(1 + (d/c)2)} where: Maximum Allowed UL TX Power is the maximum allowed uplink transmit power indicated in the system information (in dBm) and P_MAX is the maximum RF output power of the UE (dBm). The margin will be calculated for the gain factors d and c of the TF selected in the step above using 10 ms TTI length. 4) If the Margin is less than 6 dB or if the last Layer 1 message transmission on PRACH failed, then select RACH with 20 ms TTI. Otherwise select RACH with 10 ms TTI length.
Network Services
Figure 28: RACH Message Part for 10 ms Frame Length 4.2.2.3.2 Spreading Factor and RACH Slot Format of the RACH Message Part
The control part of the RACH Message Part has always a Spreading Factor (SF) equal to 256. For the data part of the RACH Message Part, there are four different RACH Slot Formats defined in 3GPP that are oneto-one mapped to the SF the UE may use when sending the RACH Message Part. The relation between the RACH Slot Format and the SF is defined as: RACH Slot Format k = 0: SF of data part equal to 256 RACH Slot Format k = 1: SF of data part equal to 128 RACH Slot Format k = 2: SF of data part equal to 64 RACH Slot Format k = 3: SF of data part equal to 32 The Channel Bit Rate per slot for the data part of the RACH Message Part is equal to 10*2k. The available SF the UE may use are broadcast via SIB 5 and SIB 6. The SF is chosen by the UE as follows: 1) The UE chooses the TTI as defined in section 4.2.2.3.1 (see p. 65) 2) The Transport Format Indicator (TFI) is chosen. The TFI is a label for a specific transport format within a transport format set. It is used in the interlayer communication between MAC and Layer 1 each time a transport block (TB) set is exchanged between the two layers on a transport channel. For Lucents 03.01 release, only one TB size is allowed: 232 bits (TFI 1). The physical layer combines the TFI information from different transport channels to the Transport Format Combination Indicator (TFCI). The TFCI is transmitted in the physical control channel to inform the receiver which transport channels are active for the current frame. See the figure below for completeness.
Network Services
Figure 29: TFI Illustration 3) With this information the UE will select the minimum SF supported by the UE and allowed by the UTRAN that is supporting the chosen TTI and TFI. The UE vendor design determines how the UE will react if the UE cannot select a proper SF. The UE may choose another TFI, which means it may not fulfill the reporting criteria (measurement results on RACH) as requested by SIB 5/SIB 6. The following table shows the SF and TFCI the UE may use for the different TTI/TFI combinations.
Chosen TTI 10 ms 20 ms
Chosen TFI (TB Size) 1 (232 bits) 1 (232 bits)
RACH Slot Format k / SF to be used 2 / 64 1 / 128
TFCI indicated on Physical Layer 1 1
Table 15: SF and TFCI Used for Different TTI/TFI Combinations 4.2.2.3.3 Scrambling Code of the RACH Message Part
The Scrambling Code (SC) of the RACH Message Part is the same SC used for the RACH Preamble part. For one PRACH, the same code number is used for both scrambling codes, i.e. if the PRACH Preamble scrambling code is used Sr-pre,m then the PRACH Message Part scrambling code is Sr-msg,m, where the number m is the same for both codes. It should be noted that using different RACH Preamble signatures will result in having a particular channelization code in the RACH Message Part. As an example, using RACH Preamble signature 0 means that the DPCCH part of the RACH Message Part uses channelization code C(256, 15) where 256 is the spreading factor and 15 is the channelization code number. Furthermore, the DPDCH part of the RACH Message Part will use channelization code C(SF, 0) where SF can be between 64 and 256.
4.2.2.3.4
RACH Message Part Power
In order to improve the detection of the RACH Message Part, and thus increase the RACH success rate, the RACH Message Part must be transmitted at a higher power compared with the acknowledged RACH
Network Services
Preamble. The total power of the RACH Message Part, the power of the DPDCH (PRACH_Msg_Part_DPDCH) and of the DPCCH (PRACH_Msg_Part_DPCCH) is calculate as:
Figure 30: RACH Message Part Power Settings PRACH_MSG_Part_Total [dB] = ACK_Preamble_Power + Ceil[PowerOffsetPpm + 10 log10(1+(d / c)2)] PRACH_MSG_Part_DPDCH [dB] = Ceil[10 log10(1+(d / c)2)] PRACH_MSG_Part_DPCCH [dB] = ACK_Preamble_Power + PowerOffsetPpm where: Ceil is a function that rounds a floating number to the first not smaller integer, e.g. ceil(2.4) = 3, ceil(10) = 10 ACK_Preamble_Power is the power of the last transmitted RACH Preamble that has been acknowledged by the Node B on the AICH. PowerOffsetPpm [dB] is the power offset between power of the acknowledged RACH Preamble and the power of the DPCCH. c and d are used by the UE to control the DPCCH/DPDCH relative power. The PRACH data to control transmit power ratio is equal to (d / c)2. Note that the total power of the RACH Message Part is limited by the maximum power allowed on the RACH that is determined by sIB3MaxAllowedULTxPower (or sIB4MaxAllowedULTxPower) that are broadcasted on the BCCH via SIB3 (or SIB4). These parameters have an impact on the cell selection/reselection criteria and should be set according to the corresponding power class of the UE. If the calculated power PRACH_Msg_Part_Total is greater than the maximum allowed power, PRACH_Msg_Part_Total is set to the maximum allowed power and the ratio between DPDCH and DPCCH remains the same according to the settings of c and d. The gain factors c and d are used during the spreading and scrambling of the PRACH as depicted below:
Network Services
Figure 31: Spreading of the RACH Message Part After applying the channelization codes cd and cc to the DPDCH and DPCCH respectively, the real-valued spread signals are weighted by gain factors, c for the DPCCH and d for the DPDCH. At every instant in time, at least one of the values c and d has the amplitude 1.0. The -values are quantized into 4 bit words and the quantization and signaling values are presented in the table below.
Signalling values for c and d 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Quantized Amplitude ratios c and d 1.0 14/15 13/15 12/15 11/15 10/15 9/15 8/15 7/15 6/15 5/15 4/15 3/15 2/15 1/15 0/15
Table 16: Quantization of Gain Factors c and d 4.2.2.3.5 Phase 3 Parameter Settings
The parameters associated with this Phase of the Random Access Procedure are presented in the table below.
Network Services
Parent Object TFC
Parameter Name GainFactorBc
Recommended Setting 7 (7/15)
Range 1 - 15
Short Description Used by the UE as the gain factor for the control part of the RACH Message Part (DPCCH) Used by the UE as the gain factor for the data part of the RACH Message Part (DPDCH) Used by the UE to calculate the power offset between the power of the acknowledged preamble and the power of the DPCCH.
TFC
GainFactorBd
15 (1.0)
1 - 15
TFC
PowerOffsetPpm
0 dB
-5 to +10 [dB]
Table 17: Phase 3 RACH Message Part Parameter Settings GainFactorBc This parameter sets the power of the PRACH control part relative to that of the data part. If this parameter is set too low, the data part of the PRACH radio frame will be received at too high a power level and waste uplink capacity. If it is set too high, the data part of the PRACH radio frame will be received at a very low power and the message may not be reliably decoded. This parameter depends on the setting of GainFactorBd. Either one of these two parameters must be set to 15 (which equates to 1.0). See chart above. GainFactorBd This parameter sets the power of the PRACH data part relative to that of the control part. This parameter is set to the highest value to ensure that the power of the DPDCH is always higher than the power of the DPCCH. If it is set too low, the data part of the PRACH radio frame will be received at a very low power and the message may not be reliably decoded. PowerOffsetPpm The PowerOffsetPpm parameter establishes the offset of the control part of the message relative to the last transmitted (acknowledged) preamble. If the parameter is set too small, decoding of the RACH message part may be unreliable. If the parameter is set too large, too much uplink capacity may be consumed. Its setting has to be considered along with setting of the parameter constantVal since low values of constantVal lead RACH Preambles to be detected at a very low Eb/No, thus to send the RACH Message Part at a power level too low to be decoded correctly by the Node B. High values improve the RACH success rate but also increase UL interference. Current recommended setting for constantVal and PowerOffsetPpm can be considered as a trade-off between achieving high RACH success rates and minimizing UL interference. Setting of this parameter also depends on the PRACH preamble detection threshold, which depends on Node B implementation. If the Node B has this value set relatively high to achieve a low probability of false alarm, then the PowerOffsetPpm can be set to a relatively low value. Vice versa, if the Node B sets the detection threshold to a relatively low value because it can tolerate a relatively high probability of false alarm, then the PowerOffsetPpm should be set to a relatively large value. Lucents recommendation that can be found in the Access Procedures Translation Application Notes is 3 dB. The following analysis provides insight into the rationale for that recommendation. The RACH message average Eb/No is found as:
Network Services
Eb ,message No
Ec , preamble No
d2 + Power Offset Pp - m + 10 log 1 + 2 + G p c
where Gp is the processing gain in dB and s correspond to the data and control gain factors. Therefore, the Power Offset Pp-m should be set such that
Power Offset Pp-m =
Eb ,message No
E c , preamble No
d2 10 log 1 + 2 G p + Implementation Margin c
If the coding rate is and when accountings for implementation margin (noisy pilot reference, quantization, tracking loop noise variance), the required message Eb/No for 1% BLER in single path Rayleigh fading and dual receive antennas is ~8 dB. Conditioned on the preamble being detected, the received preamble Ec/No is approximately equal to the setting of constantVal. For example, if constantVal = -27 dB, c=7, d=15, and the number of information bits per frame is 84, we get: Pp-m = 8 + 27 10log(1+ 225/49) 10log(38400 / 84) = 0.92 dB The Lucent recommended parameter setting includes 2-4 dB to allow for some additional margin. However, with our current settings as illustrated above, PowerOffsetPpm is set within appropriate margins for sufficient performance.
4.2.2.4
RACH Overload Control
Before the concept of overload control is introduced, it is important to understand how an operator can prioritize UEs that want access to the network as well as restrict access to the network in the case of an overload situation. This is accomplished by using Access Classes (AC) and Access Service Classes (ASC). AC is only applied in idle mode (e.g. for initial access through RRCConnectionRequest message). ASC may be used also during connected mode according to the MAC layer logical priority assigned to each logical channel. There are in total 16 ACs (AC0,., AC15). Normal subscribers are randomly assigned to AC0 to AC9. AC10 is reserved for users initiating emergency calls. Access Classes 11 to 15 can be allocated for special users (including emergency services). For each AC one ASC is assigned. There are a total of 8 ASCs available (ASC#0, , ASC#7). The ASC enumeration corresponds to the order of priority (ASC#0 = highest priority, ASC#7=lowest priority). The mapping between AC and ASC is indicated in SIB5. As a default in Lucents software version 03.01, the default mapping is: For AC0 to AC9: ASC#1 is taken For AC10 to AC15: ASC#0 is taken It will be seen that ASCs are used indirectly (via persistency value Pi) for RACH overload control. Furthermore, it is possible to restrict RACH resources available for the access procedure statistically. The resources for RACH Access can be limited for each ASC by static limitation of the number of available RACH Preamble signatures and/or RACH Preamble sub-channels.
Network Services
RACH Overload control is implemented in order to control UL interference. The Lucent RACH Overload control utilizes the algorithm below: 1) The Node B monitors UL traffic via RSSI measurements estimating the Uplink Load and reports to the RNC the results given by load_UL if certain reporting criteria are met (this will be described further in the section on Call Admission Control). 2) In order to reduce the collisions of different RACH accesses in the same cell, PRACH partitioning is required. The established PRACH partition is broadcast on SIB5. Each ASC can use different partitions of the PRACH physical resource and its probability of getting a partition (or transmitting on that partition) is determined by a persistency value. The persistence value Pi is associated with each ASC via the Dynamic Persistency Level (N = 1, , 8) that is broadcast on SIB7. The RNC determines the Dynamic Persistency Level as follows: N is equal to persistLow, if load_UL >= thrCACUL N is equal to persistHigh, if load_UL < thrCACUL The parameter thrCACUL represents the load percentage above which a new cell will be blocked due to uplink overload. This parameter will also be discussed further in the section on Call Admission Control. 3) The UE receives the Dynamic Persistence Value, N, from the RNC (via SIB7) and calculates the Persistency Value P(N) based on the following formula: P(N) = 2-(N-1) 4) The UE also receives the persistence scaling factors si that are broadcast via SIB 5 (and also possibly SIB6). Since in 03.01, the RNC does not support the scaling factor parameter, it is not broadcast via SIB and the default value 1 is used for s2, , s7. 5) Depending on the ASC, the UE calculates the Persistency Value PI as follows: Pi is equal to 1 for ASC#0 Pi is equal to P(N) for ASC#1 Pi is equal to si * P(N) for ASC# i, i = 2, , 7 (Note that from the statement above, si will always be 1 due to the limitation in 03.01). 6) The UE generates a random number R, 0 <= R <=1 and if R <= Pi, then the UE can start with the first Power Ramping Cycle (see Figures 23 & 24). So, for example, suppose N = 5, Pi = 2-(5-1) = 6.25%. This implies that the UE has a 6.25% chance of passing the persistence check. With this RACH Overload Control mechanism the UE(s) determine their transmission/retransmission probability, thus the load on the RACH is controlled.
4.2.2.5
RACH Overload Control Parameter Settings
Listed below are parameters which affect RACH Overload Control and the recommended settings.
Network Services
Parent Object
Parameter Name
Recommended Setting
Range
Short Description Dynamic persistence level used to determine the persistence value which randomizes the UE preamble transmission on the RACH and provides UL load control. In order for RACH Overload Control to work properly persistLow must be greater than or equal to persistHigh. Dynamic persistence level used to determine the persistence value which randomizes the UE preamble transmission on the RACH and provides UL load control. In order for RACH Overload Control to work properly persistHigh must be less than or equal to persistLow.
LCell
persistLow
1 to 8
LCell
persistHigh
1 to 8
Table 18: RACH Overload Control Parameters persistLow By setting this parameter to 6, the UE(s) will have a 3.1% chance of passing the persistence check if load_UL >=thrCACUL. Increasing its value leads to reducing the chance of a UE passing the persistence thus to further reduction in the RACH loading. Note that RACH Overload Control is also affected by thrCACUL parameter settings. persistHigh By setting this parameter to 2, the UE(s) will have a 50% chance of passing the persistence check if load_UL < thrCACUL. Decreasing its value (e.g. to 1) leads to increasing the chance of a UE passing the persistence check to 100% thus to further increasing in the RACH loading. Higher values would decrease the chances of the UE to access the RACH. Note that RACH Overload Control is also affected by thrCACUL parameter settings.
4.2.2.6
Retransmission of the RACH Message Part
After reception and successfully decoding of an ACK that is sent by the Node B on the AICH, the MAC layer initiates the Physical Layer to send the RACH Message Part. In the case of RRC Connection establishment procedures, the RACH Message Part will include the RRCConnectionRequest message. In the case where the UE wants to perform a Cell/URA Update, the RACH Message Part will include the CellUpdate/URAUpdate message. After reception and successful decoding of the RACH Message Part the RNC will send on the FACH the RRCConnectionSetup message (RRC Connection Establishment) or URA/Cell Update Confirm message (Cell/URA Update procedure). When not receiving an answer by the RNC on the FACH, the UE may decide to resend the RACH Message Part again.
4.2.2.6.1
Retransmission of the RACH Message Part: RRC Connection Establishment Procedure
For the initial RRCConnectionRequest message, the UE sets its internal counter V300 to 1, for subsequent transmission of the RRCConnectionRequest message the UE increments V300 by 1. Also when sending the RRCConnectionRequest on the RACH, the UE sets its guard timer T300 to t300 [unit in ms]. The UE then listens on the FACH for the RRCConnectionSetup message. Upon reception, the UE will stop timer T300 and move from idle mode to connected mode (i.e. Cell_DCH). Afterwards, the UE will send the RRCConnectionSetupComplete message on the DCH.
Network Services
If the timer T300 expires without receiving the RRCConnectionSetup message on the FACH, the UE compares its internal counter V300 to the value set for n300. If V300 is equal to or less than n300, the UE will reset timer T300, increase counter V300 and transmit a new RRCConnectionRequest message immediately. In case the counter V300 is greater than n300, the UE will enter the idle mode and the procedure ends. The UE may indicate a connection failure to the NAS. The values for t300 and n300 are made known to the UE via SIB1. See the illustrated process below:
Figure 32: Basic RRC Connection Establishment Procedure (Successful) 4.2.2.6.2 Retransmission of the RACH Message Part: Cell/URA Update Procedure
The Cell/URA Update procedure works in a similar manner as illustrated for the RRC Connection Establishment. When sending the CellUpdate/URAUpdate message on the RACH, the UE sets its guard timer T302 to t302 [unit also in milliseconds] and resets its internal counter V302. For the initial Cell/URA Update message, the UE sets its internal counter V302 to 1. For subsequent transmission of Cell/URA Update, the UE increments the counter V302. The UE then listens on the FACH for the Cell/URA Update Confirm message. Upon reception, the UE will stop timer T302 and the procedure ends. If timer T302 times out without receiving the Cell/URA Update Confirm message on the FACH, the UE checks to see if V302 is equal to or smaller than n302. If this is the case, the UE will reset timer T302, increase counter V302 and transmit a new Cell/URA Update message immediately. In case the counter V302 is greater than n302, the UE will enter the idle mode and the procedure ends. The values for t302 and n302 are made known to the UE via SIB1. The process is illustrated below.
Network Services
Figure 33: Basic Cell/URA Update Procedure (Successful) 4.2.2.6.3 Retransmission of the RACH Message Part Parameter Settings
The following table summarizes the recommendations for the parameters associated with the retransmission of the RACH Message Part. Parent Object Recommended Setting
Parameter Name
LRNC
t300
t300_1200
Range 100, 200, 400, 600, 800, 1000, 1200, 1400, 1600, 1800, 2000, 3000, 4000, 6000, 8000 [ms] 0 to 7 [Integer] 100, 200, 400, 600, 800, 1000, 1200, 1400, 1600, 1800, 2000, 3000, 4000, 6000, 8000 [ms]
Short Description UE guard timer that is supervising the RRCConnectionSetup procedure when the UE is waiting for the RRCConnectionSetup message.
LRNC
n300
Defines the number of times that the UE is allowed to send the same RRC Connection Request message UE guard timer that is supervising the Cell/URA Update procedure when the UE is waiting for the CellUpdateConfirm/URAUpdateConfirm message
LRNC
t302
t302_4000
Network Services
Parent Object LRNC
Parameter Name n302
Recommended Setting 2
Range 0 to 7 [Integer]
Short Description Defines the number of times that the UE is allowed to send the same CellUpdate/URAUpdate message.
Figure 34: Guard Times for RACH Message Part T300 This parameter defines the maximum time from transmission of the RRC Connection Request message to the reception of the RRC Connection Setup message. If t300 is chosen too short, the UE consumes resources unnecessarily by resending the request before a UTRAN response may be received. Also, the retransmission might occur under similar RF channel conditions as the previous (failed) transmission. If t300 is chosen too long, the call setup delay increases unnecessarily. It is important to note that the UE starts the t300 timer after transmission of the RRC Connection Request message and stops t300 when it receives the RRC Connection Setup message. At expiry of t300 the UE retransmits the RRC Connection Request message if it has not retransmitted n300 requests yet. Otherwise, the UE enters Idle Mode. The recommended value for t300 is a tradeoff between UTRAN processing time, time-selectivity of the RF channel, and call setup delay. The value chosen is based upon the access parameter study performed by Qualcomm in the Seattle-Tacoma FOA cluster. See the chart below.
Figure 35: t300 Parameter Study from Seattle-Tacoma
Network Services
N300 This parameter defines the maximum number of retransmissions of the RRC Connection Request message. If n300 is set too low, the RRC connection might fail due to temporarily insufficient RF conditions. If n300 is set too high, UE battery power and UL capacity are wasted by persistently trying to establish an RRC connection in insufficient RF conditions. T302 This parameter represents the length of time that the UE hast to wait for a positive reaction after sending a CELL UPDATE message to the Node B. When the UE is in the Cell_FACH or Cell_PCH state, it performs a cell update procedure whenever it reselects a cell. After sending the CELL UPDATE message to the new cell, the UE will start to decode the FAC in search of a response from the Node B. If no response is received before the timer t302 expires, the CELL UPDATE message is retransmitted. This procedure may be repeated until the maximum number of retransmissions is reached (defined by parameter n302). This information is sent to the UE in SIB2. N302 This parameter is the maximum number of times that the UE is allowed to send the CELL UPDATE message. See the process description in the previous paragraph. This information is also sent to the UE in SIB2.
4.2.2.7
Access-related Performance Measurements
In Lucents current software release (03.01/P1-Lite), the following performance measurements are relevant for the access procedure. ChannelOccupRateRACH The counter ChannelOccupRateRACH is the ratio of the total RACH bits received to maximum bits available for RACH usage (service rate) per granularity period. The total RACH bits received is the sum of RACH bits in transport blocks (excluding padding) received by the MAC layer. The service rate is derived from the maximum number of transport blocks, size of the transport blocks, and transmission time interval for the RACH. PercentFACHOccupancy This measurement provides the percentage of the average FACH occupancy per granularity period. If gives an indication of the FACH traffic loading NumRRCConnAtt This measurement is the number of received RRCConnectionRequest messages sent by the UE to the RNC. RRC.AttConnEstab.sum This measurement provides the total number of RRC Connection Establishment attempts. This includes the repeat attempts from the same UE. RRC.FailConnEstab.SetupIncomplete This counter represents the number of RRC connection attempt failures when the RNC does not receive the RRCConnectionSetupComplete message from the UE. This includes failures for repeated RRC connection attempts from the same UE. RRC.FailConnEstab.sum This measurement provides the total number of failed RRC connection establishments. This includes rejects for repeated RRC connection attempts from the same UE.
Network Services
RRC.FailConnEstab.CAC - Whenever the RNC sends a RRC Connection Reject message with cause Congestion, this counter will be incremented. Congestion will occur due to resource limitations identified during Call Admission Control (CAC). RRC.FailConnEstab.RLSetupFailure Whenever the RNC sends an RRC Connection Reject message with cause unspecified for the case where the SRNC receives a Radio Link Setup Failure message, this counter will be incremented. RRC.SuccConnEstab.sum This measurement provides the total number of successful established RRC Connections. RRC.SuccConnEstab.call This measurement captures the number of successful RRC Connection Establishments for calls being setup. NumGoodRACHTransBlock This counter is incremented when a RACH TB with a good CRC is received by the RNC. This counter is per cell. NumBadRACHTransBlock This counter is incremented when a RACH TB with a bad CRC is received by the RNC. This counter is per cell.
4.2.3
Call Establishment
Once the UE has successfully entered Idle Mode, it can then access the system by originating CircuitSwitched (CS) or Packet-Switched (PS) session with acceptable Accessibility measures (or have CS/PS calls terminate to the UE). This section focuses on the procedures associated with establishing either a CS or PS call.
4.2.3.1
Circuit-Switched (CS) Mobile Origination/Termination
The establishment of a voice call begins with either a RACH on the uplink or a Page on the downlink. This section will focus on the processes and procedures required for successful establishment of a mobile originated CS call. For the mobile originated call example presented, the UE is attached to the Network in idle mode. The following steps are required to be executed IN ORDER for a CS call to be successfully completed. The only difference with the MO and MT processes is that an additional stage for Paging using procedures presented in section 4.1.4 occurs before stage 1 below. 1) RRC Connection Setup 2) Service Request / Iu Connection Setup 3) Authentication & Security 4) Call Progress Information 5) Radio Link and Radio Access Bearer (RAB) Configuration 6) Call Connection 4.2.3.1.1 RRC Connection Setup
A Radio Resource Control (RRC) connection must be established before anything can be done in UMTS. In the case of a mobile originated call, this signals the call attempt. The RRC connection is a logical connection between the UTRAN and the UE with the following characteristics:
NetOps-xxxxxND-00167 Rev. 1.3 06/02/06 Page 78 of 248 (c) 2006 Cingular Wireless
Network Services
Each UE can have only one (1) RRC connection at any time with the UTRAN. It is used by the UTRAN to track both the location and state of the UE during the life of a call or packet session. The role of the Serving RNC (SRNC) is activated upon the establishment of the RRC Connection. UE is identified with a Radio Network Temporary Identifier (RNTI) upon establishment of the RRC connection. o RNTI used for the purpose of keeping the UEs permanent identity private during over-theair signaling and consists of the UE temporary ID and the SRNC identity.
Setting up this RRC connection is accomplished via common channel signaling. This stage contains 3 distinct steps (listed below):
RRC Connection Request RRC Connection Setup RRC Connection Setup Complete
Logical Channel CCCH CCCH DCCH
Transport Channel RACH FACH RACH
Physical Channel PRACH SCCPCH PRACH
RRC Connection Request Below are listed some key parameters that can be identified from the RRC Connection Request. 1) Initial UE Identity This is the users identity with respect to the core network. If this is the first time that the user is accessing the network, the permanent UE identifier (IMSI) may be used. Otherwise, the UEs temporary identity (TMSI) is used. Using TMSI is preferred to keep the users permanent information private. 2) Establishment Cause Conveys the reason for requesting the RRC Connection. In case of a useroriginated voice call, the value will be OriginatingConversationalCall, which indicates the service is UE originated and the Quality of Service (QoS) is conversational. Other possible RRC Connection Request causes include registration or emergency calls. Below is a log illustrating the layer 3 information for a UE originated call using TEMS 6.0.
Network Services
MS1 RRC Connection Request (UL-CCCH) Time: 17:46:12.64 Command Code : 16 Length : 29 Log Code (Hex) : 0x412F 1.25 ms/40 counter (32 kHz clock) : 38 CFN : 58 1.25 ms counter : 907031801 Logical channel : (0) Uplink CCCH Rb_Id : 0 Message length : 13 initialUE-Identity InitialUE-Identity : tmsi-and-LAI tmsi-and-LAI tmsi Binary string (Bin) : 00000000000000101100001011101101 lai plmn-Identity mcc MCC : [0 ] : 3 [1 ] : 1 [2 ] : 0 mnc MNC : [0 ] : 4 [1 ] : 1 [2 ] : 0 Location area code (LAC) : 42996 (Hex 0xA7F4) establishmentCause : originatingConversationalCall protocolErrorIndicator : noError measuredResultsOnRACH modeSpecificInfo : fdd measurementQuantity : cpich-Ec-N0 cpich-Ec-N0 : (28) -10.0 (dB)
Figure 36: Example of RRC Connection Request Parameters (taken from TEMS) RRC Connection Setup Below are listed some key parameters that can be identified from the RRC Connection Setup. 1) U-RNTI The UTRAN Radio Network Temporary Identity consists of the RNTI assigned by the SRNC and the SRNC identity. This is used to identify the UE as long as the RRC connection is established. 2) RRC State Indicator This provides the state assigned to the UE upon processing of this message. The UE is instructed to stay on common channels until dedicated resources have been allocated (i.e. moved to Cell_FACH state).
Network Services
3) Radio Bearer Information This provides RB information elements, complex parameter sets, that the UE needs to setup logical channels for signaling, to map transport channels, and to assign physical channels. Below is a log illustrating the layer 3 information for a UE originated call using TEMS 6.0.
MS1 RRC Connection Setup (DL-CCCH) Time: 17:45:42.55 Command Code : 16 Length : 138 Log Code (Hex) : 0x412F 1.25 ms/40 counter (32 kHz clock) : 54 CFN : 114 1.25 ms counter : 907003231 Logical channel : (2) Downlink CCCH Rb_Id : 0 Message length : 122 RRCConnectionSetup : r3 rrcConnectionSetup-r3 initialUE-Identity InitialUE-Identity : p-TMSI-and-RAI p-TMSI-and-RAI p-TMSI P-TMSI : Hex 0xE4225A54 rai lai plmn-Identity mcc MCC : [0 ] : 3 [1 ] : 1 [2 ] : 0 mnc MNC : [0 ] : 4 [1 ] : 1 Location area code (LAC) : 425 (Hex 0x01A9) rac Routing area code (RAC) : 1 (Hex 0x01) rrc-TransactionIdentifier : 0 new-U-RNTI srnc-Identity Binary string (Bin) : 000001101000 s-RNTI Binary string (Bin) : 00000110011000001111 rrc-StateIndicator : cell-DCH utran-DRX-CycleLengthCoeff : 7 capabilityUpdateRequirement ue-RadioCapabilityFDDUpdateRequirement : True ue-RadioCapabilityTDDUpdateRequirement : False systemSpecificCapUpdateReqList SystemSpecificCapUpdateReqList : [0 ] : gsm srb-InformationSetupList SRB-InformationSetupList2 : [0 ] : rb-Identity : 1 rlc-InfoChoice RLC-InfoChoice : rlc-Info rlc-Info ul-RLC-Mode UL-RLC-Mode : ul-UM-RLC-Mode ul-UM-RLC-Mode dl-RLC-Mode DL-RLC-Mode : dl-UM-RLC-Mode rb-MappingInfo RB-MappingInfo : [0 ] : ul-LogicalChannelMappings UL-LogicalChannelMappings : oneLogicalChannel oneLogicalChannel ul-TransportChannelType UL-TransportChannelType : dch dch : 32 logicalChannelIdentity : 1 rlc-SizeList : configured mac-LogicalChannelPriority : 1 dl-LogicalChannelMappingList DL-LogicalChannelMappingList : [0 ] : dl-TransportChannelType DL-TransportChannelType : dch dch : 32 logicalChannelIdentity : 1 [1 ] : ul-LogicalChannelMappings UL-LogicalChannelMappings : oneLogicalChannel oneLogicalChannel ul-TransportChannelType UL-TransportChannelType : rach logicalChannelIdentity : 1 rlc-SizeList : explicitList explicitList RLC-SizeExplicitList : [0 ] : rlc-SizeIndex : 1 mac-LogicalChannelPriority : 1 dl-LogicalChannelMappingList DL-LogicalChannelMappingList : [0 ] : dl-TransportChannelType DL-TransportChannelType : fach logicalChannelIdentity : 1
Figure 37: Example of RRC Connection Setup Messaging (taken from TEMS) RRC Connection Setup Complete Below are listed some key parameters that can be identified from the RRC Connection Setup.
Network Services
1) Integrity Information/Ciphering Information During the connection establishment the UE sends its security capabilities to the Node B. The security capabilities include the supported UMTS integrity and ciphering algorithms as well as GSM encryption capabilities as well. 2) UE Radio Access Capability This includes radio access (FDD), UE power class, and transport/physical channel capabilities. Below is a log illustrating the layer 3 information for a UE originated call using TEMS 6.0.
MS1 RRC Connection Setup Complete (UL-DCCH) Time: 17:45:42.67 Command Code : 16 Length : 43 Log Code (Hex) : 0x412F 1.25 ms/40 counter (32 kHz clock) : 55 CFN : 140 1.25 ms counter : 907003305 Logical channel : (1) Uplink DCCH Rb_Id : 2 Message length : 27 rrc-TransactionIdentifier : 0 startList STARTList : [0 ] : cn-DomainIdentity : cs-domain start-Value Binary string (Bin) : 00000000000000000110 [1 ] : cn-DomainIdentity : ps-domain start-Value Binary string (Bin) : 00000000000000000010 ue-RadioAccessCapability accessStratumReleaseIndicator : r99 pdcp-Capability losslessSRNS-RelocationSupport : False supportForRfc2507 : notSupported rlc-Capability totalRLC-AM-BufferSize : kb150 maximumRLC-WindowSize : mws2047 maximumAM-EntityNumber : am16 transportChannelCapability dl-TransChCapability maxNoBitsReceived : b6400 maxConvCodeBitsReceived : b6400 turboDecodingSupport TurboSupport : supported supported : b6400 maxSimultaneousTransChs : e8 maxSimultaneousCCTrCH-Count : 1 maxReceivedTransportBlocks : tb32 maxNumberOfTFC : tfc128 maxNumberOfTF : tf64 ul-TransChCapability maxNoBitsTransmitted : b6400 maxConvCodeBitsTransmitted : b6400 turboEncodingSupport TurboSupport : supported supported : b6400 maxSimultaneousTransChs : e8 modeSpecificInfo : fdd maxTransmittedBlocks : tb32 maxNumberOfTFC : tfc64 maxNumberOfTF : tf64 rf-Capability physicalChannelCapability downlinkPhysChCapability maxNoDPCH-PDSCH-Codes : 1 maxNoPhysChBitsReceived : b9600 supportForSF-512 : False supportOfPDSCH : False simultaneousSCCPCH-DPCH-Reception SimultaneousSCCPCH-DPCH-Reception : notSupported uplinkPhysChCapability maxNoDPDCH-BitsTransmitted : b9600 supportOfPCPCH : False ue-MultiModeRAT-Capability multiRAT-CapabilityList supportOfGSM : False supportOfMulticarrier : False multiModeCapability : fdd securityCapability cipheringAlgorithmCap_spare15 : 0 cipheringAlgorithmCap_spare14 : 0 cipheringAlgorithmCap_spare13 : 0 cipheringAlgorithmCap_spare12 : 0 cipheringAlgorithmCap_spare11 : 0 cipheringAlgorithmCap_spare10 : 0 cipheringAlgorithmCap_spare9 : 0 cipheringAlgorithmCap_spare8 : 0 cipheringAlgorithmCap_spare7 : 0 cipheringAlgorithmCap_spare6 : 0 cipheringAlgorithmCap_spare5 : 0 cipheringAlgorithmCap_spare4 : 0 cipheringAlgorithmCap_spare3 : 0 cipheringAlgorithmCap_spare2 : 0 cipheringAlgorithmCap_uea1 : 1 cipheringAlgorithmCap_uea0 : 1 integrityProtectionAlgorithmCap_spare15 : 0 integrityProtectionAlgorithmCap_spare14 : 0 integrityProtectionAlgorithmCap_spare13 : 0 integrityProtectionAlgorithmCap_spare12 : 0 integrityProtectionAlgorithmCap_spare11 : 0 integrityProtectionAlgorithmCap_spare10 : 0 integrityProtectionAlgorithmCap_spare9 : 0 integrityProtectionAlgorithmCap_spare8 : 0 integrityProtectionAlgorithmCap_spare7 : 0 integrityProtectionAlgorithmCap_spare6 : 0 integrityProtectionAlgorithmCap_spare5 : 0 integrityProtectionAlgorithmCap_spare4 : 0 integrityProtectionAlgorithmCap_spare3 : 0 integrityProtectionAlgorithmCap_spare2 : 0 integrityProtectionAlgorithmCap_uia1 : 1 integrityProtectionAlgorithmCap_spare0 : 0 ue-positioning-Capability standaloneLocMethodsSupported : False ue-BasedOTDOA-Supported : False networkAssistedGPS-Supported : noNetworkAssistedGPS supportForUE-GPS-TimingOfCellFrames : False supportForIPDL : False rrcConnectionSetupComplete-v370ext ue-RadioAccessCapability-v370ext ue-RadioAccessCapabBandFDDList UE-RadioAccessCapabBandFDDList : [0 ] : radioFrequencyBandFDD : fdd1900 ue-PowerClass : class3 txRxFrequencySeparation : mhz190 measurementCapability compressedModeMeasCapabFDDList CompressedModeMeasCapabFDDList : [0 ] : radioFrequencyBandFDD : fdd1900 dl-MeasurementsFDD : True ul-MeasurementsFDD : True
Figure 38: Examples of RRC Connection Setup Complete Messages
Network Services
Figure 39: Illustration of RRC Connection Setup Process (including RACH procedures) 4.2.3.1.2 Service Request / Iu Connection Setup
Once the RRC connection has been established, a Service request for the voice call is sent. This is sent as a Direct Transfer message (which is routed through the SRNC) to the MSC/VLR. This also establishes the initial Iu-CS connection to the MSC/VLR. The establishment of the Iu signaling connection is accomplished with the Initial UE message, sent from the SRNC to the MSC/VLR. See the signaling diagram below. Note that this is the first time that the call has an interaction with the Core Network.
Figure 40: Illustration of Service Request/Iu Connection Setup Process
Network Services
4.2.3.1.3
Authentication and Security
In order to protect against network impersonation, UMTS applies a combination of two mechanisms: the validity of an authentication token (Authentication) and the integrity protection of the signaling messages (Security). The authentication token guarantees the freshness and the origin (home network) of the authentication challenge, protecting against replay of authentication data. The integrity protection prevents the possibility that a man or element in the middle can simply forward correct and timely authentication messages and fools both the UE and the Node B into not using encryption for subsequent communication. UMTS interoperates with GSM. This results in different versions of the authentication and key agreement procedures depending on the subscriber (moreso the SIM/USIM), the capabilities of the UE, and the capabilities of the network (and UMTS coverage area). There are several different scenarios that exist (see 3GPP TR 31.900, v6.1.0), but this discussion details the case where a UMTS subscriber connects to a UMTS network. However, since the GSM base station does not support integrity protection and only uses the GSM encryption algorithms, changes will be noted for the security mechanism for a UE authenticating on a GSM network. For the case of a UMTS subscriber on a UMTS network, both the network and UE support all UMTS security mechanisms. The authentication and key agreement follows the steps below: 1. During the RRC Connection establishment the UE sends its security capabilities to the Node B (see Figure 37 above). The security capabilities include the supported UMTS integrity and encryption algorithms and optionally the GSM encryption capabilities as well. 2. The UE sends its current TMSI to the network. If the network cannot resolve the TMSI, it requests the UE to send its permanent identity and the UE responds with its IMSI. 3. If the subscriber is not in its home network, the visited network requests authentication data from the home network. 4. The home network returns a random challenge RAND, the corresponding authentication token AUTN, authentication response XRES, integrity key IK and the encryption key CK. The home network and the USIM share a user-specific secret key K, certain message authentication functions, and certain key generating functions. 5. The visited network then sends the authentication challenge RAND and authentication token AUTN to the UE. 6. The UE verifies the AUTN and computes the authentication response. If AUTN is not correct the UE discards the message. 7. The UE sends its authentication response RES to the visited network. 8. The visited network checks whether RES=XRES and decides which security algorithms the radio subsystem is allowed to use. 9. The visited network sends the allowed algorithms to the radio subsystem and the radio access network decides which (of the allowed) algorithms to use. 10. The radio access network informs the UE of its choice in the security mode command message. The message also includes the security capabilities the network received earlier and the keys which
Network Services
will be used for integrity protection and ciphering. The keys are not transmitted over the air but rather are calculated by the UE from information received during the authentication process. 11. The UE validates the integrity protection and checks the correctness of the security capabilities. For the case where the UE wishes to connect to GSM (for example, due to lack of UMTS coverage) and the backbone components (SGSN and MSC) support UMTS, the first 7 steps of the authentication protocol listed above are carried out. The GSM BSS simply forwards the UMTS authentication traffic and the following steps are completed: 8. The MSC/SGSN decides which GSM encryption algorithms are allowed and computes the GSM Key Kc from the UMTS keys IK, CK. 9. The MSC/SGSN advises the GSM BSS of the allowed algorithms and forwards the GSM encryption key Kc. 10. The GSM BSS decides which of the allowed encryption algorithms to use depending on the ciphering capabilities of the UE. 11. The GSM BSS sends the GSM cipher mode command to the UE. This process is simplified in the diagram below.
Figure 41: Illustration of Authentication and Security Process
Network Services
MS1 Security Mode Command (DL-DCCH) Time: 17:46:14.91 Command Code : 16 Length : 42 Log Code (Hex) : 0x412F 1.25 ms/40 counter (32 kHz clock) : 29 CFN : 64 1.25 ms counter : 907033591 Logical channel : (3) Downlink DCCH Rb_Id : 2 Message length : 26 integrityCheckInfo messageAuthenticationCode Binary string (Bin) : 00110001001010001100110010110011 rrc-MessageSequenceNumber : 0 SecurityModeCommand : r3 securityModeCommand-r3 rrc-TransactionIdentifier : 0 securityCapability cipheringAlgorithmCap_spare15 : 0 cipheringAlgorithmCap_spare14 : 0 cipheringAlgorithmCap_spare13 : 0 cipheringAlgorithmCap_spare12 : 0 cipheringAlgorithmCap_spare11 : 0 cipheringAlgorithmCap_spare10 : 0 cipheringAlgorithmCap_spare9 : 0 cipheringAlgorithmCap_spare8 : 0 cipheringAlgorithmCap_spare7 : 0 cipheringAlgorithmCap_spare6 : 0 cipheringAlgorithmCap_spare5 : 0 cipheringAlgorithmCap_spare4 : 0 cipheringAlgorithmCap_spare3 : 0 cipheringAlgorithmCap_spare2 : 0 cipheringAlgorithmCap_uea1 : 1 cipheringAlgorithmCap_uea0 : 1 integrityProtectionAlgorithmCap_spare15 : 0 integrityProtectionAlgorithmCap_spare14 : 0 integrityProtectionAlgorithmCap_spare13 : 0 integrityProtectionAlgorithmCap_spare12 : 0 integrityProtectionAlgorithmCap_spare11 : 0 integrityProtectionAlgorithmCap_spare10 : 0 integrityProtectionAlgorithmCap_spare9 : 0 integrityProtectionAlgorithmCap_spare8 : 0 integrityProtectionAlgorithmCap_spare7 : 0 integrityProtectionAlgorithmCap_spare6 : 0 integrityProtectionAlgorithmCap_spare5 : 0 integrityProtectionAlgorithmCap_spare4 : 0 integrityProtectionAlgorithmCap_spare3 : 0 integrityProtectionAlgorithmCap_spare2 : 0 integrityProtectionAlgorithmCap_uia1 : 1 integrityProtectionAlgorithmCap_spare0 : 0
cipheringModeInfo cipheringModeCommand CipheringModeCommand : startRestart startRestart : uea1 rb-DL-CiphActivationTimeInfo RB-ActivationTimeInfoList : [0 ] : rb-Identity : 1 rlc-SequenceNumber : 1 [1 ] : rb-Identity : 3 rlc-SequenceNumber : 4 [2 ] : rb-Identity : 4 rlc-SequenceNumber : 1 [3 ] : rb-Identity : 2 rlc-SequenceNumber : 15 integrityProtectionModeInfo integrityProtectionModeCommand IntegrityProtectionModeCommand : startIntegrityProtection integrityProtInitNumber Binary string (Bin) : 01111101011100100000110001111111 integrityProtectionAlgorithm : uia1 cn-DomainIdentity : cs-domain ue-SystemSpecificSecurityCap InterRAT-UE-SecurityCapList : [0 ] : InterRAT-UE-SecurityCapability : gsm gsmSecurityCapability GsmSecurityCapability_a5_7 : 0 GsmSecurityCapability_a5_6 : 0 GsmSecurityCapability_a5_5 : 0 GsmSecurityCapability_a5_4 : 0 GsmSecurityCapability_a5_3 : 0 GsmSecurityCapability_a5_2 : 1 GsmSecurityCapability_a5_1 : 1
Figure 42: Security Mode Command Message (taken from TEMS) 4.2.3.1.4 Call Progress Information
The purpose of this segment of the call establishment process is to initiate the requested service. The UE Connection Manager (CM) sends the Setup request to its peer entity in the MSC. Key parameters in the Setup message include: Calling party number Called party number Supplementary services information
Network Services
Calling Line ID Suppression or Presentation The purpose of the Call Proceeding message is to provide an indication to the UE that the call setup request has been received and is in progress. Both the Setup and Call Proceeding messages are sent between the MSC and UE via direct transfer procedure. The UTRAN is not involved in the contents or processing of either of these messages. See the diagram illustrated below.
Figure 43: Illustration of Call Progress Information Process 4.2.3.1.5 Radio Link and Radio Access Bearer (RAB) Configuration
Once the service request has been initiated, the Core Network (i.e. MSC) requests the UTRAN to allocate the necessary radio resources via a Radio Access Bearer (RAB) Assignment Request. Once the RAB is set up, the MSC proceeds to route the call to the PSTN (Public Switched Telephone Network). The RAB assignment is the mechanism for the core network to notify the UTRAN of the appropriate Quality of Service (QoS) and attributes to deliver the requested service. At this point the Serving RNC asks the Node B if it can create the necessary radio links require to complete the session. This is where the Load Control algorithms are executed (will be explored later). Radio Link Setup The purpose of the Radio Link Setup is to establish the networks portion of the communications link to the user equipment (UE). Since this example illustrates a voice call being set up, this is the point where the physical layer of the radio interface protocol stack is established. This carries the voice traffic over the air interface. The Radio Link Setup message provides all of the information necessary to handle the requested service. These items include:
Network Services
Dedicated Channel (DCH) Information Information specific to each of the dedicated transport channels. In AMR speech, each class of bits (A, B, and C) is assigned a DCH. Transport Format Set (TFS) Allowed formats within each DCH Frame Handling Priority Allows the Physical Layer to intelligently multiplex DCH data onto the DPCH. Node Synchronization Parameters Parameters used to allow the RNC and Node B to achieve synchronization immediately following this Radio Link Setup Radio Link Timing and Power Control parameters Indication of timing to be used for the UEs dedicated physical channel (DPCH). It includes the frame and chip offsets to the Node Bs frame timing for the Primary Common Control Physical Channel (PCCPCH). Radio Access Bearer The UMTS Bearer Service consists of two parts, the Radio Access Bearer (RAB) Service and the Core Network Bearer Service. Both services reflect the optimized way to utilize the UMTS Bearer Service over the network topology taking into consideration mobility and UE subscriber profiles. In this field guide, the focus will be on the Radio Access Bearer and its role in the establishment of a CS or PS connection. A Radio Access Bearer is basically a connection between the UE and the MSC (in the case of a CS connection) or between the UE and the Serving GPRS Support Node (SGSN) (in the case of a PS connection). The RAB is set up according to the requested service after the signaling connection is established. In the case of UE initiated connections where a RAB does not already exist, the requested service is sent in the RACH Message Part. Although the requested service could be sent by the UE, all Radio Access Bearers are initiated by the Core Network. UMTS does not pass any application-specific information to the RNC or Node B during call setup or maintenance, so the only differentiation of service allowable via the 3GPP standards is to use Quality of Service (QoS) differentiation. UMTS supports a range of Quality of Service encompassing delay, bandwidth, and error rates. At the top level QoS is sub-divided into four major categories: Conversational Two-way transport between human users (examples include real-time voice, realtime video, and interactive games) Streaming One-way transport to human destination (examples include real-time audio and realtime video) Interactive (with priorities) Two-way transport between user and server (examples include web browsing, email, database retrieval) Background One-way transport to machine destination (examples include fax/backdrop delivery of email, file transfer, database download) At subscription each user will have a subscription profile registered into the HLR including for one or more subscribed PDP contexts the highest QoS class allowed and the maximum and/or guaranteed data rates allowed. When a user initiates a request to establish a PDP context, the core network checks the user requested QoS against the subscription data and either responds if the request is accepted, or may reject/re-negotiate to an acceptable level if the request exceeds the users subscribed capability. When a request to establish a RAB is received by the UTRAN, the QoS parameters are checked and a selection made on the preferred choice of radio channel to support this quality when the UE is active. The chart below illustrates each QoS class and the associated characteristics (along with delay requirements). The illustration provides insight to how error tolerance is related to the QoS classes and supported applications.
Network Services
Traffic Class
Fundamental characteristics
Conversational Class Preserve time relation (variation) between information entities of the stream. Conversational pattern (stringent and low delay) 120 ms (TS 23.107) Voice
Streaming Class Preserve time relation (variation) between information entities of the stream 200 ms (80% of UMTS bearer) Streaming Video
Interactive Class
Background Class Destination is not expecting the data within a certain time. Preserve payload content. 800 ms (80% of UMTS bearer) background download of emails
Request response pattern. Preserve payload 320 ms (80% of UMTS bearer) Web browsing
UMTS Delay Objectives Example of Application
Table 19: UMTS QoS Classes
Table 20: UMTS QoS Class vs. Error Tolerance Matrix The following types of Radio Access Bearers (RABs) are supported by the Lucent UTRAN in 03.01. SRB (for DCCH) UL DL 3.4kbps 3.4kbps 3.4kbps 3.4kbps CS RAB UL PS RAB UL 128kbps 128kbps 16kbps 8kbps 16kbps 8kbps
Type -
DL -
Type Interactive/ Background Interactive/ Background Streaming/ Unknown Interactive/ Background Streaming/ Unknown Interactive/ Background
DL 128kbps 64kbps 64kbps 8kbps 128kbps 8kbps
3.4kbps
3.4kbps
3.4kbps
3.4kbps
Network Services
SRB (for DCCH) UL DL 3.4kbps 3.4kbps
Type Conversation al/Unknown
CS RAB UL 12.2kbps
DL 12.2kbps
Type Streaming/ Unknown Interactive/ Background Streaming/ Unknown Interactive/ Background Interactive/ Background Streaming/ Unknown
PS RAB UL 16kbps 8kbps 128kbps 8kbps 128kbps 16kbps 8kbps 64kbps 8kbps 64kbps
DL 128kbps 8kbps 16kbps 8kbps 64kbps 64kbps 8kbps 16kbps 8kbps Max bit rate dependent on UE category Max bit rate dependent on UE category
3.4kbps
3.4kbps
Conversation al/Unknown Conversation al/Unknown
12.2kbps
12.2kbps
3.4kbps
3.4kbps
12.2kbps
12.2kbps
3.4kbps
3.4kbps
Conversation al/Unknown
12.2kbps
12.2kbps
Interactive/ Background Streaming/ Unknown Interactive/ Background Interactive/ Background Interactive/ Background
3.4kbps
3.4kbps
Conversation al/Unknown
12.2kbps
12.2kbps
3.4kbps
3.4kbps
3.4kbps
3.4kbps
128kbps
Table 21: Lucent Radio Access Bearers (RABs) Radio Bearer Setup The purpose of the Radio Bearer Setup is to establish the UEs portion of the radio interface protocol stack. The RRC protocol communicates all of the required parameters needed for the UE to establish its half of the radio link. For a voice call setup, the physical layer, Medium Access Control (MAC), and Radio Link Control (RLC) layers are all involved and play key roles. In the UTRAN, the radio interface protocol is distributed between the Node B (physical layer) and the Serving RNC (MAC and RLC). Therefore, the Radio Bearer Setup contains the relevant information given to the Node B for setting up the physical layer, as well as the necessary parameters to configure the upper layers. Below are some selected parameters included in Radio Bearer Setup. Security Parameters The information necessary to perform integrity protection for signaling and ciphering for the voice traffic is provided to the UE. Radio Resource Control (RRC) State Indicator For this example the UE is assigned a dedicated channel resulting in Cell_DCH. Radio Access Bearer (RAB) Information This identifies the set of logical channels and their mapping to transport channels as well as other parameters required to start the Radio Link Control layer processing.
Network Services
Uplink/Downlink Transport Channels Defines the set of transport channels and the allowed set of transport formats which the UE can send/receive to/from the network. Physical Channel Information Defines the channelization code to be used, the uplink scrambling code, power control parameters, and all other information required to complete the physical layer connection between the Node B and UE. Now that the Radio Bearer Setup is complete, the UTRAN must respond to the circuitswitched core network (CS-CN). The Serving RNC sends a message to the MSC to indicate the successful establishment of the Radio Access Bearer. Embedded in the message is the necessary information to complete the setup of the Iu bearer for the voice call. This is the RNC to MSC connection identifier allocated to this user. The UTRAN and UE can now initiate the service. Each stage for Radio Link Setup and RAB Establishment is illustrated below.
Figure 44: Illustration of Radio Link and Radio Access Bearer (RAB) Configuration 4.2.3.1.6 Call Connection
Finally the MSC, prior to the signaling illustrated below, has routed the call to its destination. The Alert message indicates to the UE that the far end has been notified of an incoming call. At this time, the UE will typically generate ringing tones to alert the caller that progress is being made. The only thing that is left is for the person being called is to pick up the phone. Once this is done, the core network notifies the UE with the Connect message that the far end has answered. This will cause the UE and core network to activate their speech coders and begin transmitting and receiving speech.
Network Services
Figure 45: Call Connection - The Conversation Begins 4.2.3.2 Packet-Switched (PS) Mobile Origination/Termination
The procedure for setting up a packet session (R99) UMTS session is essentially the same as for the circuit-switched call flow described above. This section will focus on the processes and procedures required for successful establishment of a UE originated PS call. For the UE originated call example presented, the UE is assumed not to be attached to the SGSN in idle mode. The following steps are required to be executed for a PS call to be successfully completed. 1) Establish an RRC Connection to the UTRAN 2) Establish an Iu connection to the Core Network 3) Make an Attach Request* 4) Security and Authentication 5) Request PDP Context Activation* 6) Radio Link / Radio Bearer Setup 7) Activate PDP Context at the GGSN* 8) Data Session Setup Complete (i.e. Transfer Data)
Network Services
Since several of these steps have been examined in the section related to the circuit switched call, the focus of this section will be on the steps that differ from the CS call setup flow (denoted above by *). 4.2.3.2.1 UMTS Attach
If the parameter att sent in System Information Block 1 is set to 1, the UE must establish a signaling connection to notify the Packet Switched Core network that it is powered on and within the network coverage area. The UMTS Attach procedure registers the UE and establishes a logical link with the 3GSGSN. The Packet Mobility Management Layer (PMM) builds an Attach message destine for its peer in the 3G-SGSN. This message informs the 3G-SGSN of the location of the UE. In order to transfer this information, the UE must interface with the RNC which then interfaces with the 3G-SGSN. First the UE must establish an RRC Connection (as discussed in the previous section). Once the RRC connection is established, the UMTS Attach message can be transferred over the air to the Node B and the Node B can forward it to the RNC. The RNC receives the data (the attach message) and passes it to the 3G-SGSN. The appropriate header is added and an Iu signaling connection is established. This data is sent to the 3G-SGSN using the Initial UE message. The PMM layer in the 3G-SGSN recognizes the data as the UMTS Attach message. In response, it communicates with the Home Location Register (HLR) and creates an Authentication Request destined for the UE. This actually begins the authentication process. A downlink message is used to send the Authentication Request message from the 3G-SGSN to the UTRAN. This is done by sending the Authentication Request through the existing Iu and RRC Connections to the UE. At this point the UTRAN acts merely as a pass-thru for sending messages between the 3G-SGSN and the UE. Once the UE receives the data, it rebuilds the Authentication Request message sent by the 3G-SGSN, interprets it, and replies with an Authentication Response. The 3G-SGSN verifies the UE information with the HLR. If the results are satisfactory (i.e. RES = XRES see authentication discussion in the previous section), the UE is registered with the network. The PMM layer sends an Attach Accept message communicating this information to the UE. The UE will send an Attach Complete message if the network assigned a new P-TMSI value. At this point, the UMTS Attach is complete (i.e. a logical link exists between the UE and the 3G-SGSN). See the flow diagram below.
Network Services
Figure 46: UMTS Attach Procedure
4.2.3.2.2
PDP Context Activation
Now the UE must establish a PDP Context so that it can communicate on external packet data networks. The UE requests a dynamic IP address via this PDP Context Activation procedure. First the UE sends an Activate PDP Context Request message to the 3G-SGSN. The SGSN does not have a connection to the external packet network so it must forward this request to a GGSN. The GGSN serves as the interface to the external packet data network. The 3G-SGSN determines the appropriate GGSN to forward this request based on the input parameters from the UE. This PDP Context Request message contains some key parameters related to the QoS of the requested packet service such as: Class of service: interactive class such as a Web service Throughput: expected rate of data transfer of the application Delay: indication of how much delay can be tolerated in the system Reliability: indication of the level of reliability needed for this service See the sample PDP Context Request message below.
Network Services
MS1 Activate PDP Context Request Time: 09:18:08.85 qualcommHeader Command Code : 16 Length : 167 Log Code (Hex) : 0x713A 1.25 ms/40 counter (32 kHz clock) : 48 CFN : 120 1.25 ms counter : 675280463 Direction : (1) To network Message length : 150 TI flag : (0) The message is sent from the side that originates the TI Transaction identifier : 0 Protocol discriminator : (10) GPRS session management messages Message type : 65 Requested NSAPI NSAPI value : (5) NSAPI 5 Requested LLC SAPI LLC SAPI value : (3) SAPI 3 Requested QoS Delay class : (0) Subscribed delay class Reliability class : (0) Subscribed reliability class Peak throughput : (6) Up to 32 000 octets/s Precedence class : (0) Subscribed precedence Mean throughput : (31) Best effort Traffic Class : (3) Interactive class Delivery order : (0) Subscribed delivery order Delivery of erroneous SDU : (0) Subscribed delivery of erroneous SDUs Maximum SDU size : (0) Subscribed maximum SDU size Maximum bit rate for uplink : (72) 128 kbps Maximum bit rate for downlink : (104) 384 kbps Residual BER : (0) Subscribed residual BER SDU error ratio : (0) Subscribed SDU error ratio Transfer delay : (0) Subscribed transfer delay Traffic Handling priority : (0) Subscribed traffic handling priority Guaranteed bit rate for uplink : (0) Subscribed Guaranteed bit rate for downlink : (0) Subscribed Requested PDP address PDP type organisation : (1) IETF allocated address PDP type number : (33) IPv4 address No PDP address included Access point name Access Point Name : isp.cingular
Figure 47: PDP Context Activation sample message While this activity is taking place, the SGSN also initiates the Radio Access Bearer Assignment message to the UTRAN in order to assign the radio bearers associated with the UE. Once the Radio bearer and Radio Access Bearer have been set up, the 3G-SGSN is notified. A GTP-U tunnel between the UTRANs SRNC and the 3G-SGSN is set up. Tunneling is the process of wrapping the network layer packets (IP packets) in another header so that they can be routed through the UMTS PLMN IP backbone network. Inside this network, packets are routed based on the new header alone and the original packet is carried as freight. Once they reach the far side of the UMTS network (GGSN), they are unwrapped and continue on their way through the external network. From this point onward they are routed based on their original header. The use of tunneling within the UMTS network helps solve the mobility problem for packet networks and eliminates the complex task of protocol interworking.
Network Services
The GPRS Tunneling Protocol (GTP-C) sends a Create PDP Context Request to the GGSN. The GGSN allocates a PDP Address for the UE and sends a Create PDP Context Response back to the 3G-SGSN. At this point another GTP-U tunnel is established between the 3G-SGSN and the GGSN. The GTP tunnel remains until the PDP context is deactivated.
Figure 48: PDP Context Activation Procedure At this point, all the bearer channels are set up for carrying traffic. The PDP Context Accept indicates to the UE that the core network has provided the UE with resources needed for packet transfer. The core network also provides the negotiated QoS which may or may not be the same as the requested QoS from the UE.
Network Services
4.3
4.3.1
4.3.1.1
Mobility and Connection Management

Load Control
Cingular Strategy
4.3.1.2
Overview
The main advantage of UMTS radio interface is its flexibility in resource management allowed by the WCDMA access technique. However, to exploit this flexibility, it is necessary to design an efficient call admission control (CAC) scheme able to adapt the number of active calls in each cell according to interference levels and power availability. With 2G systems, like GSM, the decision if a new call can be accepted or not can be considered an easy task since it only depends on the available number of channels in the cell. On the other side, the planning of the number of channels and the frequencies (and MAIOs, HSNs, FN Offsets) to be assigned to each cell is not an easy job. With UMTS, the two problems have changed their roles. The network planning has no more to deal wit the frequency allocation problem, so in a sense it is an easier task. On the contrary, the call admission control can be come a very complex problem due to the soft capacity of the UMTS system. As a matter of fact, the system is mainly interference limited and the number of connections can not specify the actual capacity in each cell. The acceptance of a new connection depends on the SIR (signal-tointerference ratio) values achievable by each existing connection once a new one is activated. These values are functions of the emitted powers, which due to power control mechanisms (to be discussed later), depend on the subscribers positions. Since the power available at each Node B is limited, the number of users that can be served is large if the UEs are close to the Node B and small if all UEs are far away. Due to the WCDMA nature of UMTS, the following problems need to be addressed: The system may become unstable in high load situations The interference is originated not only from the primary serving cell (intra-cell interference) but also from other cells (inter-cell interference) The resource consumption of a certain service depends on the Quality of Service (QoS) in terms of data rate, BLER, and delay requirements. Load control addresses these issues and deals with the efficient management of available radio resources to balance high network capacity and good service reliability. The Load control algorithms should be able to handle an overload situation. This problem becomes very important if there are more services requested than what can be granted. The power control mechanisms adopted by UMTS controls the power emitted on each channel in order to keep the SIR at the receiver at a target value. In normal conditions, an equilibrium point is reached after some algorithm iterations and all channels achieve the SIR target (see Power control section). The acceptance of a new call can create two possible situations: The new call is safely activated since a new equilibrium can be reached
Network Services
The new call is erroneously admitted since a new equilibrium can not be reached due to the interference levels and power constraints. In this last case the Power Control raises the power levels until some power limit is reached and some call is dropped due to the low value of SIR. Lucents UMTS Load Control includes: Load Estimation Call Admission Control (CAC) Congestion Control (ConC) Dynamic Bearer Control (DBC) RACH Overload Control Aggregate Overload Control (AOC) Note: With the introduction of HSDPA in Lucents 03.01 release, there are several new concepts for PS data connections. It should be noted that all algorithms described here are only based on R99 capable UEs. Lucent has a Translation Application Note on HSDPA (as well as other features) covering the concepts and parameters of this feature. 4.3.1.3 Load Estimation
The UTRAN regularly estimates the current load in the system. For the purpose of load control, the following two measurements are used: Received Total Wideband Power (typically referred to as RSSI Received Signal Strength Indicator) Transmitted Carrier Power (typically referred to as TSSI Transmitted Signal Strength Indicator) The load is estimated in the uplink from the Received Total Wideband Power (RTWP). From that measurement, the uplink load is obtained in the RNC by:
Load_UL = 1 10 NR [ dB ] / 10
where:
NR [ dB ] = RSSI [ dBm ] noise _ floor [ dBm ]

NR is the Noise Rise in dB, RSSI is the reported measurement in dBm. The noise_floor is separately estimated from the lowest reported RSSI values. In the downlink the load is determined by the Transmitted Carrier Power. The downlink load is directly given by the reported TSSI, which is defined as:
load _ DL = TSSI = current _ pwr[W ] / max_ pwr[W ]

Current_pwr is the actual transmitted power and max_pwr is the maximum available power. The power rise, PR, can be defined as:
PR[dB] = total_power [dBm] pilot_power [dBm]

Network Services
Total_power is the reported measurement converted in dBm and the pilot_power is the constant power setting of the CPICH also in dBm. A filtering of the RSSI/TSSI measurements is performed in the Node B using a simple forgetting filter. Having the filter factor a, the updated filtered value Fn is given by:
Fn = (1 a)*Fn - 1 + a*Mn
Here Fn-1 denotes the old filtered result and Mn is the latest received measurement result. In order to initialize the averaging filter, F0 is set to M1 when the first measurement result from the physical layer measurement is received. The filter coefficients k are set by OMC parameter filterCoefficientDL/UL. The relation between k and filter factor a is:
a = 2-k/2
The pre-defined values of k=6 for both directions lead to a filter factor of approximately a~0.1. The internal Node B measurement interval before layer 3 filtering is defined as T=100 ms in TS 25.133. The following parameters are defined for load measurements. Parent Object Parameter Name measurementRe porting Recommended Setting Range pERIODIC eVENTTRIGGER ED Short Description This is set per RNC. This parameter indicates what type of measurement reporting is used. This parameter will not be modifiable for 03.01. This is set per Cell. This hysteresis time causes the load measurements to be less sensitive to short peaks. However this also causes additional delay until the load control can react upon changes. It should only be lowered if the load control is proven to work to slow. This is set per Cell. Interval of periodical load measurements for the estimation of the daily_low_RSSI measurements. Should not be a critical parameter. This is set per cell. This time value can be modified if the time of lowest traffic is known from service measurements of the network
LCell
eVENTTRIGGERED
LCell
hysteresisTime
2000ms
1000 to 30000 ms (in steps of 1000 ms)
LCell
measurementPeri odLong
15 min
-35 to -10 [dB]
LCell
timeMeasureCont rol
120 (corresponds to 2:00:00)
0 to 1435 mins (in steps of 5 mins)
Network Services
Parent Object
Parameter Name
Recommended Setting
Range cOEFF_0 cOEFF_1 cOEFF_2 cOEFF_3 cOEFF_4 cOEFF_5 cOEFF_6 cOEFF_7 cOEFF_8 cOEFF_9 cOEFF_11 cOEFF_13 cOEFF_15 cOEFF_17 cOEFF_19 cOEFF_0 cOEFF_1 cOEFF_2 cOEFF_3 cOEFF_4 cOEFF_5 cOEFF_6 cOEFF_7 cOEFF_8 cOEFF_9 cOEFF_11 cOEFF_13 cOEFF_15 cOEFF_17 cOEFF_19
Short Description
LCell
filterCoefficientUL
cOEFF_6
This is set per cell. Filter coefficient for uplink load measurements. Larger values cause the load measurements to be less sensitive to short peaks. However this also causes additional delay until the load control can react on changes.
LCell
filterCoefficientDL
cOEFF_6
This is set per cell. Filter coefficient for downlink load measurements. Larger values cause the load measurements to be less sensitive to short peaks. However this also causes additional delay until the load control can react on changes. (value 6: about 0.75 seconds filter time constant)
Table 22 Load Measurement Related Parameters measurement Reporting the common measurement report using report characteristics Event F is used for load measurement in Lucent. According to 25.331, Event F is defined as: the Measurement Reporting procedure (Report A) is initiated always when the measured entity falls below the Measurement Threshold 1 and stays there for the Measurement Hysteresis Time (T1 in figure below). If Report Periodicity IE is provided Node B shall also initiate Measurement Reporting procedure periodically. (In 03.01, only event triggered measurement report is used. Therefore, no periodic reporting is available. ) When the Report A conditions have been met and the measured entity rises above the Measurement Threshold 2 and stays there for the Measurement Hysteresis Time (T1) Measurement Reporting procedure (Report B) is initiated and the periodic reporting is terminated.
Network Services
Measured entity
T1 Measurement Hysteresis Time
T1
T1
T1
Measurement Threshold 2 Measurement Threshold 1 Time
Report A
Periodic Reports
Report B
Report A
Periodic Report
Measurement Reports
Figure 49 Measurement Reports In 03.01, the following reporting criteria are used: The Node B reports the RSSI value to the RNC if the RSSI rises above one of the thresholds (thr_RSSI1, thr_RSSI2, or thr_RSSI3 Threshold 2 ) and stays there for the hysteresisTime The Node B reports the RSSI value to the RNC if the RSSI value falls below one of the thresholds (thr_RSSI1, thr_RSSI2, or thr_RSSI3 Threshold 1 ) and stays there for the hysteresisTime. For the purpose of estimating the noise_floor, the Node B reports the RSSI value of each cell to the RNC periodically every measurementPeriodLong The Node B reports the TSSI value to the RNC if the TSSI rises above one of the thresholds (thr_TSSI1, thr_TSSI2, or thr_TSSI3 threshold 2) and stays there for hysteresisTime The Node B reports the TSSI value to the RNC if the TSSI value falls below one of the thresholds (thr_TSSI1, thr_TSSI2, or thr_TSSI3 threshold 1) and stays there for the hysteresisTime.
The 3 thresholds for UL and DL result in 6 measurement events for the Node B. For Uplink: o o o thr_RSSI1 = 20 10log(100 thrDBCUL) + noise_floor thr_RSSI2 = 20 10log(100 thrCACUL) + noise_floor thr_RSSI3 = 20 10log(100 thrConCUL) + noise_floor
The noise floor is calculated using the following formula: noise_floor = filterConstantkNF * noise_floor + (1 - filterConstantkNF) * daily_low_RSSI
Network Services
filterConstantkNF is default as 6/7. Initial noise floor is defined by parameter initialNoiseFloor, default at -102 dBm. Daily low RSSI is lowest of all samples taken for the day For Downlink : o o o thr_TSSI1 = thrDBCDL (DBC DL load threshold) thr_TSSI2 = thrCACDL (Call Admission Control load threshold) thr_TSSI3 = thrConCDL (Congestion Control load threshold)
hysteresisTime In the case of event_triggered measurement reporting, the hysteresisTime is the time duration that the RSSI/TSSI values are below their related thresholds before an RSSI/TSSI measurement report is triggered. Those thresholds are defined above with their corresponding settable parameters. In 03.01, all 6 measurement events (DL and UL) use the same hysteresisTime. measurementPeriodLong The Node B will report the RSSI value of each cell when the value rises above or drops below a pre-defined threshold. To ensure that measurements of the noise floor of the cell are still reported if the RSSI value does not rise above or drop below the respective thresholds, the RSSI value of a cell is also reported periodically to the RNC. This periodic reporting is referred to as long reporting. timeMeasureControl once a day, a UL measurement control procedure is executed to obtain Uplink noise measurement for load control purpose. It will be processed at timeMeasureControl for each cell or at (re)initialization of a cell. The value should be set to a time when the network is likely to be at a low level of loading filterCoefficientUL/filterCoefficientDL These two parameters define the filter coefficient (k) that is used for filtering RSSI (UL) and TSSI (DL) measurements in the Node B. In 03.01, FilterCoefficientUL is used for all 3 UL measurement events (based on 3 RSSI thresholds). And FilterCoefficientDL is used for all 3 DL measurement events (based on 3 TSSI thresholds) 4.3.1.4 Call Admission Control (CAC)
Call Admission Control is triggered on the reception of a RRC Connection Establishment Request message and therefore controls whether a user can establish a new RRC connection for call setup. Only if the load for both uplink and downlink is below the defined threshold, can a RRC connection be established.
Network Services
Emergency service gets higher priority than normal calls.
Figure 50 Admission Control flow chart thrCACxx stands for thrCACDL and thrCACUL thresholds. Based on Lucent simulation, the default of both thresholds is set to 75%. Due to problems with RSSI spikes during UE attaches it is recommended to turn off all UL threshold by setting it to 100%. Also one important fact is there is no admission control for SHO. The reasons for doing so are: higher probability of call drop if SHO is denied due to admin control due to UE not having suitable serving cell(s). higher probability of call drop due to additional delay for SHO due to rate reconfiguration (in case lower rate is to be offered for R99 PS). higher probability of call drop for other UEs due to higher interference from serving cell(s) (for the UE to do SHO) if SHO is denied due to admin control.
The call is admitted during SHO. Overload, if any, is dealt with AOC and congestion control. 4.3.1.5 Congestion Control (CongC)
Congestion control seeks to reduce the load if CAC and Dynamic Bearer Control (DBC) did not succeed to keep the load within acceptable limits. If the load exceeds the congestion control threshold for either UL or DL, the data rate of all packet data users is reduced and UEs with the lowest rate are sent to URA_PCH or idle. After a defined time interval the load is checked again and the rate reduction is repeated if the value still exceeds the threshold. The figure below illustrates how the load relates to the noise rise (UL) and the power rise (DL).
Note: in future release (03.03), number of connection to be rate reduced or dropped is configurable to allow gradual drop/rate reduction
Network Services
thr_ConC stands for thrConCUL and thrConcDL parameters, for UL and DL congestion respectively. Default of both are 100%, effectively disabling Congestion control function. This is because that Lucent believes that the implementation of reducing rate has worse impact than instability problem caused by overload, and Lucent proprietary Aggregated Overload Control algorithm is effective in handling overload situation when ConC is switched off.
Figure 51 Congestion Control flow chart The timer conCWatiTime defines the minimum interval after which the next reduction in data rate can happen if the load is still above the congestion control threshold. When Congestion Control is triggered, all active PS RAB will be reduced to the next lower data rate (DL: 384k 128k 64k 32k). UEs which already have only a PS RAB with the lowest possible data rate (32k) will be sent to URA_PCH state, while UEs not supporting URA_PCH will be sent to idle. With the current u03.01 implementation the DL rate will be reduced even if the UL was causing ConC to trigger. This behavior will be modified for later releases (03.03) to allow independent DL and UL trigger. If the UE has a PS RAB with the lowest rate and a simultaneous CS connection the PS RAB will be torn down. CS bearers are not affected by ConC. 4.3.1.6 Dynamic Bearer Control (DBC)
Dynamic Bearer Control is invoked whenever a certain amount of resources is requested (i.e. when establishing a new radio bearer), during the transition to Cell_DCH state from other states, or when a data rate increase is triggered. Depending on the data rate of the requested radio bearer, the current load is checked against the appropriate thresholds and only if the load is below the threshold is the radio bearer granted. Dynamic bearer control is executed when a certain amount of new resources is requested. when establishing a new RB, e.g. during the transition from idle state to CELL_DCH state after the successful establishment of the RRC connection. This is triggered on the reception of a RAB Assignment Request message from the CN. when transferring from URA_PCH state to CELL_DCH state for the support of packet data, triggered is a Cell_Update RRC message from the UE when a service based data rate increase is triggered by a buffer occupancy measurement event. when the UE is transitioning from CELL_FACH to CELL_DCH triggered by increased traffic demand (UL/ DL) or RAB establishment request causing a RB reconfiguration message.
Network Services
If a 384k bearer is requested the environment status is checked. This flag indicates that a UE is located near the cell edge if the measured CPICH Ec/Io is below the limit defined by the parameter ecI0thr. If the environment status is cell edge a 384 kbps bearer is not granted. Then the dynamic bearer control performs a check of the cell load against the thresholds thrDBCxx (high data rate user: 384kbps DL, 64kbps UL) or thrCACxx (low data rate user, voice) according to the QoS of the requested service. If the load check passes for the uplink and the downlink, then the service request is granted and the UTRAN proceeds on completing either the RAB assignment procedure, the transition from URA_PCH/CELL_FACH state to CELL_DCH state or the service triggered increase. If the load check fails for at least one of the directions, then the service request is denied: o causing either a RAB establishment failure when the UE tried to establish a RAB. In this case the RNC sends to the CN a RAB Assignment Response message with cause No resource available. In case of a failure moving from URA_PCH to CELL_DCH/ CELL_FACH the UE is sent back to URA_PCH or kept in CELL_FACH, respectively. In case of failure to increase the data rate, the rate is kept at the previous one.
Please note that the DBC check is not performed in case of incoming soft HO legs. This is intended because the additional interference due to a denied soft HO is much worse than the additional load in the cell.
max. rate allowed by DBC (DL Only)
Figure 52 Dynamic Bearer Control flow chart
Network Services
4.3.1.6.1
State Transition
Figure 53 State Transition Figure above illustrates the currently supported states and transition among them. For details on explanation on these various states, see section 4.2.1. Transition between CELL_DCH, CELL_FACH and URA_PCH In order to preserve radio resources the UE is switched from CELL_DCH to CELL_FACH, when it requires only a fairly low data rate. The measured data rate for UL and DL must be below the defined thresholds for a period of time then the UE will be reconfigured to CELL_FACH. It should be noted that two separate sets of data rate thresholds exist, one for a congested RACH or FACH and one for the not congested case. If the UE has established a simultaneous CS call the PS bearer will not be reconfigured even if the trigger conditions for CELL_FACH would be fulfilled. When the UE needs to transfer a larger volume of data it needs to be reconfigured to CELL_DCH. This is triggered again by data rate thresholds. In this case if the rate is above the threshold for one of the links the UE will be reconfigured to CELL_DCH. Additionally there are also a trigger based on buffer occupancy for the downlink and uplink. The uplink buffer occupancy is measured by the UE and sent as measurement report (Event 4A) to the UTRAN. Another possibility to trigger a transition to CELL_DCH is a RAB establishment request in Cell_FACH state. In order to preserve further radio resources the UE is switched from CELL_FACH to URA_PCH, when it no longer needs dedicated resources. This switch is triggered by the detection of inactivity (no data transmission on neither UL nor DL) over a certain time period (tInactFACHPCH). It should be noted that in u03.01 the transition from CELL_FACH to URA_PCH is going via CELL_DCH. This is causing an additional transition delay which is not performance relevant as the UE was idle for some time already. Whenever the UE has established a simultaneous CS connection the PS bearer is reconfigured to 8kbps in case of inactivity on the PS RAB. in current release, transition from CELL_FACH to URA_PCH is going via CELL_DCH. This is inefficient from resource perspective. In future release 04.03, CELL_FACH to URA_PCH will be direct transition. For UE that does not support URA_PCH mode, it will be sent to idle mode. E911 related concerns: For RRC Redirect to work, the UE has to be in Idle state. If it is in Cell FACH or URA PCH, RRC Redirect would not work. In that case, an emergency call will be completed as a Phase 1 call in UMTS. This is a compliance issue within Cingular.In 16.70 or later release, URA PCH will be suppressed in cells where RRC Redirect is active to meet compliance requirements. Hence, when tInactFACHPCH timer expires, the UE
Network Services
will be transitioned to idle from Cell FACH instead of transitioning to URA PCH if RRC Redirect is active. Otherwise, UE will move to URA PCH Mode.
DL data rate is averaged over a period defined by avTimeRDLDCHFACH UL data rate is averaged over a period defined by avTimeRULDCHFACH DL & UL data rate measurement is sampled at frequency of nSampRateDCHFACHDataRate Cell DCH Cell FACH DL data rate is averaged over a period defined by avTimeRDLFACHDCH UL data rate is averaged over a period defined by avTimeRULFACHDCH DL BO is averaged over period defined by avTimeBODLFACHDCH. DL & UL data rate measurement is sampled at frequency of nSampRateFACHDCHDataRate DL BO measurement is sampled at frequency of nSampRateDLBOFACHDCH and combined from the values of DTCH and DCCH. (weighting of DCCH is defined by dCCHBuffOccupancyMultiplier). UL BO measurement is done by UE.
No
If RACH load > rACHCongThresd or FACH load > rFACHCongThresh ?
yes
Is any one of the following conditions met? 1. { DL data rate > rthDLFACHDCH or UL data rate > rthULFACHDCH ] and tTrigFACHDCH timer expires } 2. { DL BO > bOthDLFACHDCH and timer tTrigBOFACHDCH expires } 3. UE sends a event 4A report ( UE will send this report if UL BO > fACHULBOTrafVolMeas.rcThreshold for the time of fACHULBOTrafVolMeas.rcTimeToTrigger)
No
Use rthClearDLDCHFACH & rthClearULDCHFACH
Use rthConDLDCHFACH & rthConULDCHFACH
yes
Move to CELL DCH mode. Use initialRateDLDCH for DL RAB and 128 kbps for UL RAB (as default)
Stay on CELL_DCH
DL data rate < rthClearDLDCHFACH and UL data rate < rthClearULDCHFACH And tTrigDCHFACH timer expires And DL BO < bOthDLDCHFACH
No
No
DL data rate < rthCongDLDCHFACH and UL data rate < rthCongULDCHFACH And tTrigDCHFACH timer expires And DL BO < bOthDLDCHFACH
Another RNC triggered FACH to DCH transition is not allowed for a previously reconfiguration until tPendFACHDCH timer expires; Another UE triggered FACH to DCH transition is not allowed for a previously reconfiguration until fACHULBOTRafVolMeas.rcMeasPendingTriggerTIme timer expires;
Stay on FACH mode
yes
yes
Is tInactFACHPCH expires without any DL or UL activities?
No
Another DCH to FACH transition is not allowed for a previously reconfiguration until tPendDCHFACH timer expires Move to CELL FACH mode Any data transmission
yes
Move to URA_PCH mode (*)
Another CELL_FACH to URA_PCH transition is not allowed for a previously reconfiguration until tPendFACHPCH timer expires
At any time, a RRC connection release will move UE from CELL_DCH, CELL_FACH or URA_PCH to Idle mode
*: in 16.70 or later release, UE will move to Idle mode if at least one cell in URA area has RRC redirect feature turned ON. This effectively disable URA_PCH.
Figure 54 State Transition detailed diagram with parameter names
Network Services
4.3.1.6.1.1
Transition from CELL_DCH to URA_PCH
This is not recommended due to low resource efficiency.

4.3.1.6.2 Data Rate Adaptation
Supported RAB in 03.01 release: Speech AMR12.2 64 UL/64 DL 64 UL / 128 DL 64 UL / 384 DL 128 UL / 64 DL 128 UL / 128 DL 12.2 Speech + 64 UL / 64 DL 12.2 Speech + 64 UL / 128 DL 12.2 Speech + 128 UL / 64 DL 12.2 Speech + 64 UL / 384 DL 1.8 Mbps 128 UL / HS 64 UL / HS
PS I/B
Speech + PS I/B
HSDPA max DL bit rate HSDPA I/B UL
Table 23 Supported RAB in 03.01 Transport Channel Type Instance number 1 2 3 4 5 6 7 8 9 10 11 12 13 - 17 18 19 20 21 22 Defines Transport Channel Type DCCH signaling at 3.4kbps Voice - RAB subflow 1 Voice - RAB subflow 2 Voice - RAB subflow 3 64kbps CS UL 64kbps/DL 64 kbps PS UL 64kbps/DL 384 kbps PS UL 32kbps/DL 32 kbps PS UL 64kbps/DL 128 kbps PS 57.6kbps CS 8kbps PS HSDSCH/64 Int+BG RNC internal (non configurable) HSDSCH/32 Int+BG HSDSCH/128 Int+BG UL 128k / DL 64k PS Int/BG UL 128k / DL 128k PS Int/BG UL 128k / DL 384k PS Int/BG
Network Services
DL data rate increase For Buffer Occupancy (BO) measurement, see 25.321, 8.2.2.c for more details. Lucent implements BO measurement in the exact way of specified in the spec.
Figure 55 DL Data Rate Increase
Network Services
Figure 56 DL data rate decrease
UL Data Rate Increase / Decrease UL Data Rate Adaptation is not available in 03.01. Initial UL data rate for R99 and HSDPA call is set to 128 kbps. So UE supporting 128 kbps RAB will be given 128 kbps RAB in UL at call setup. If 128 can be not be granted, 64 kbps will not be given as Rate Negotiation is not available in 03.01. 4.3.1.7 RACH Overload Control
Apart from the parameters for measurement control and the load thresholds, there are also some parameters controlling the timing of possible retries and the persistency of RACH attempts from the UE in order to prevent overload on the RACH itself. These parameters were introduced in the Random Access section. It should be noted that the persistency values for RACH overload control are chosen depending on whether the UL load exceeds a threshold value defined by thrCAC_UL. With 03.01 the RACH load is
Network Services
further checked against thr_RACH. If either load is too high, persistency will be reduced. This avoids general UL load overload as well as RACH overload due to too many RACH access attempts. The RACH overload control strategy is described in an earlier section.
Parent Object LCell
Parameter Name thrRACH
Recommended Setting
Range 0 to 100%
50%
Short Description This is set per cell. The Random Access Channel (RACH) threshold is the RACH load percentage where the persistency value is changed.
RACH Overload Control Parameters 4.3.1.8 Aggregate Overload Control
This feature is implemented to prevent overload of the power amplifier of the Node B. Therefore, it is closely related to the load control features discussed in the previous sections. As Aggregate Overload Control (AOC) is preventing overload of the Node B power amplifier, it is purely based on downlink load measurements. Even though it has the same aim as other load control algorithms for the downlink, it is still important as it compensates the effect of power amplifier overload on a higher time resolution. This is necessary to prevent non-linear operation and overheating of the amplifiers. The idea of AOC is to scale down the power of all users and overhead channels while keeping the power of the pilot channel (P-CPICH) if an overload situation occurs. Several loops are used to control the average power over different averaging intervals. Basically, AOC is reducing the risk of power amplifier overload by sacrificing link quality for the duration of the overload situation.
4.3.1.9
Engineering Guidelines for Load Control related parameters
4.3.1.9.1
Summary Table
parameternamein database range (pERIODIC, eVENTTRIGGE RED) CingularDefault description Thisparameterindicateswhattypeof measurementreportingisused.This parameterwillnotbemodifiableforU03.01 butbefixedaseventtriggered. Thishysteresistimecausestheload measurementstobelesssensitivetoshort peaks.Howeverthisalsocausesadditional delayuntiltheloadcontrolcanreactupon changes.Itshouldonlybeloweredifthe loadcontrolisproventoworktoslow. Intervalofperiodicalloadmeasurementsfor theestimationofthedaily_low_RSSI measurements.Shouldnotbeacritical parameter. Thistimevaluecanbemodifiedifthetime oflowesttrafficisknownfromservice measurementsofthenetwork
parameter name Measurement Control related parameters
measurementReporting
Eventtriggered
hysteresisTime
1000...30000 [ms]1000msstep
2000
measurementPeriodLong
1to60[min]
15
timeMeasureControl
0...1439[min] (corresponding to0:00to23:59)
120
Network Services

Filtercoefficientforuplinkload measurements.Largervaluescausetheload measurementstobelesssensitivetoshort peaks.Howeverthisalsocausesadditional delayuntiltheloadcontrolcanreacton changes. (value6:about0.75secondsfiltertime constant) Filtercoefficientfordownlinkload measurements.Largervaluescausetheload measurementstobelesssensitivetoshort peaks. Howeverthisalsocausesadditionaldelay untiltheloadcontrolcanreactonchanges. (value6:about0.75secondsfiltertime constant) LoadthresholdfortheULcalladmission controlandULdynamicbearercontrolfor voice.Lowerthresholdsresultinearlier blockingofnewcallsandwilllowerthe overallsystemload.Duetoproblemswith RSSIspikesduringUEattachesitis recommendedtoturnoffallULthreshold. LoadthresholdfortheDLcalladmission controlandDLdynamicbearercontrolfor 64k/128kPSserviceandvoice.Lower thresholdsresultinearlierblockingofnew callsandwilllowertheoverallsystemload. Thegivenvalueisagoodtradeoffbetween blockingandservicequalityandbetween outageandoverloadforthelowerrateDL PSservice,respectively. LoadthresholdfortheULcongestion control.Higherthresholdswouldresultina higherprobabilitytoreachtheinstability conditionandthereforetodeterioratethe transmissionqualityforalldatacarriers.Due toproblemswithRSSIspikesduringUE attachesitsrecommendedtoturnoffallUL threshold. LoadthresholdfortheDLcongestion control.Higherthresholdswouldresultina higherprobabilitytoreachtheinstability conditionandthereforetodeterioratethe transmissionqualityforalldatacarriers. Settingthistimeallowstodefinetheinterval afterwhichConCistriggeringadatarate decreaseagainiftheloadisstilltoohigh.If ConChasbeendisabledthisvaluehasno effect. LoadthresholdfortheULdynamicbearer controlfor64kPSservice.Lowerthresholds resultinearlierDBCblockingandwilllower theoverallsystemload.Duetoproblemwith RSSIspikesduringUEattachesitis recommendedtoturnoffallULthreshold.
filterCoefficientUL
cOEFF_0,1,2,3, 4,5,6,7,8,9,11, 13,15,17,19
cOEFF_6
filterCoefficientDL
cOEFF_0,1,2,3, 4,5,6,7,8,9,11, 13,15,17,19
cOEFF_6
thrCACUL
0...100[%]
100%
CACRelated
thrCACDL
0...100[%]
75%
thrConCUL
0...100[%]
100%
Congestion Control thrConCDL 0...100[%] 100%
conCWaitTime
100to10000[ms] 100msstep
2000
DBCrelated parameters
thrDBCUL
0...100[%]
75%
Network Services

LoadthresholdfortheDLdynamicbearer controlfor384kPSservice.Lowerthresholds resultinearlierDBCblockingandwilllower theoverallsystemload.Thegiventhreshold isagoodtradeoffbetweenoutageand overloadforthe384kPSservice. Thisthresholddefinesthecoverageareain whichtheenvironmentstatusiscell center.OnlywithinthisareaDBCallowsto geta384kRAB.Decreasingthisvaluewill extendtheareawhere384kcallscanbe initiatedbutwillalsoreducesystemcapacity (numberofusers). DirecttransitionfromCELL_DCHto URA_PCH.TRUEmeanstheUEwillmove directlytoURA_PCH,FALSEmeanstheUE willgofirsttoCELL_FACH. DirecttransitionfromURA_PCHto CELL_DCH.TRUEmeanstheUEwillmove directlytoCELL_DCH,FALSEmeansthe UEwillgofirsttoCELL_FACH. ThresholdfordeterminingifaCellsRACH channelisinacongestedstate. ThresholdfordeterminingifaCellsFACH channelisinacongestedstate. Parameterdefinestheintervalinwhich FACHmeasurementsarereportedtoRRC. Downlinkdataratethresholdfor CELL_DCHtoCELLFACHtransitionwhen theFACHisnotincongestedstate. UplinkdataratethresholdforCELL_DCHto CELL_FACHtransitionwhentheRACHis notincongestedstate. Downlinkdataratethresholdfor CELL_DCHtoCELL_FACHtransitionwhen theFACHisincongestedstate. UplinkdataratethresholdforCELL_DCHto CELL_FACHtransitionwhentheRACHis incongestedstate. AveragingperiodforDLratemeasurement inCELL_DCH. AveragingperiodforULratemeasurement inCELL_DCH. Parameterdefinesthegranularityofthe Uplinkanddownlinkdataratemoving averagefilterinCELL_DCHfordetermining CELL_DCHtoCELL_FACHtransition. Indicatestheperiodoftimeduringwhichit isforbiddentosendanynewDCHtoFACH measurementreportsevenifthetriggering conditionisfulfilled. Theperiodoftimebetweenthetimingof eventdetectionandthetimingoftriggering theDCHtoFACHmeasurementreportfor allcriteriabeingsatisfied. Page 113 of 248 (c) 2006 Cingular Wireless
thrDBCDL
0...100[%]
50%
ecI0thr
24.0to0[dB]
13
stateTrans.directDCHPCH State Transition Control stateTrans.directPCHDCH
True/False
FALSE
True/False
FALSE
rACHCongThresh RACH/FACH Congestion fACHCongThresh fACHOccupancyReportRat e Cell_DCHto Cell_FACH
0to8 0to100 0to10000[TTI]
2 90 1000
rthClearDLDCHFACH
0to100000[bps]
2500
rthClearULDCHFACH
0to100000[bps]
2500
rthConDLDCHFACH
0to100000[bps]
2000
rthConULDCHFACH
0to100000[bps]
2000
avTimeRDLDCHFACH avTimeRULDCHFACH
0to10000[ms] 0to10000[ms]
3000 3000
nSampRateDCHFACHDat aRate
0to1000[10ms]
12
tPendDCHFACH
0to16000step 20[ms]
2000
tTrigDCHFACH
0to10000step 100[ms]
2000
Network Services

Thresholdforunfiltereddownlinkbuffer occupancybeingbelowthisvaluebefore transitionfromCELL_DCHtoCELL_FACH. Downlinkdataratethresholdfor transitioningfromCELL_FACHto CELL_DCH. Uplinkdataratethresholdfortransitioning fromCELL_FACHtoCELL_DCH. AveragingperiodforDLratemeasurement inCELL_FACH. AveragingperiodforULratemeasurement inCELL_FACH. AverageperiodforDLbufferoccupancy measurementinCELL_FACH. Parameterdefinesthegranularityofthe uplinkanddownlinkdataratemoving averagefilterinCELL_FACHfor determiningCELL_FACHtoCELL_DCH transition. Parameterdefinesthegranularityofthe downlinkbufferoccupancymovingaverage filtermeasuredinCELLFACHforfilter measuredinCELL_FACHforCELL_FACH toCELL_DCHtransition. Downlinkbufferoccupancythresholdfor transitioningfromCELL_FACHto CELL_DCH. Indicatestheperiodoftimeduringwhichit isforbiddentosendanynewFACHtoDCH measurementreportsevenifthetriggering conditionisfulfilled. Theperiodoftimebetweenthetimingof eventdetectionandthetimingoftriggering theFACHtoDCHmeasurementreportfor bufferoccupancymeasurements. Theperiodoftimebetweenthetimingof eventdetectionandthetimingoftriggering theFACHtoDCHmeasurementreportfor dataratemeasurements. ParameterdefinesascalingontheDCCHfor bufferoccupancytriggerfromCELL_FACH toCELL_DCH.Asettingof1.0meansthat thebufferoccupancyisthesumofDCCH andDTCHbufferoccupancy.Asettingof0.0 meansthatthebufferoccupancyispurely theDTCHbufferoccupancy.Asettingof>1 meansthattheDCCHbufferoccupancyhas ahigherweightingthantheDTCH. ParameterwillonlybeupdatedbyRNC followingRNCreset.
bOthDLDCHFACH
0to65535[byte]
125
rthDLFACHDCH
0to100000[bps]
3000
rthULFACHDCH avTimeRDLFACHDCH avTimeRULFACHDCH avTimeBODLFACHDCH
0to100000[bps] 0to100000step 1000[ms] 0to100000step 1000[ms] 0to10000[ms]
3000 10000 10000 200
nSampRateFACHDCHDat aRate
0to1000[10ms]
12
nSampRateDLBOFACHD CH Cell_FACHto Cell_DCH (RNCtrigger)
0to1000[10ms]
bOthDLFACHDCH
0to65535[byte]
500
tPendFACHDCH
0to16000step 20[TTI]
2000
tTrigBOFACHDCH
0to10000[ms]
tTrigRateFACHDCH
0to10000step 100[ms]
1000
dCCHBuffOccupancy Multiplier
0to5000step0.1
Cell_FACHto Cell_DCH(UE trigger)
fACHULBOTrafVolMeas. measQtyqty
rLCBUFFERPAY LOAD, aVERAGERLCB UFFERPAYLOA D, vARIANCEOFR LCBUFFERPAY LOAD
aVERAGERLCBU FFERPAYLOAD
Measurementtypeforatrafficvolume measurement.
Network Services

Timeintervaltotakeanaverageora varianceonatrafficvolumemeasurement. Note:onlyvalidforAverageRLCbuffer payloadandVarianceofRLCbufferPayload measurementquantity. Indicatesthestatesinwhichtrafficvolume measurementreportingshallbeconducted. Indicatestheperiodoftimeduringwhichit isforbiddentosendanynewmeasurement reportswiththesameTrafficVolumeevent identityevenifthetriggeringconditionis fulfilled.Notethat0removesthequantity fromtheSIB.
fACHULBOTrafVolMeas. measQyaverageTime
20to260step20 [ms]
200
fACHULBOTrafVolMeas. measValidity
cELLDCH, aLLBUTCELLD CH,aLLSTATES tIMEAFTERTRI GGER_0,250, 500,1000,2000, 4000,8000,16000 tRAFFICVOLU METHR_8,16, ...1024,2K,3K, ....384K,512K, 768K tIMETOTRIGGE R_0,10,20,40, 60,80,100,120, 160,200,240, 320,640,1280, 2560,5000 tIMEAFTERTRI GGER_0,250, 500,1000,2000, 4000,8000,16000 aM_RLC, uM_RLC 0to1000[s]
aLLBUTCELLDCH
fACHULBOTrafVolMeas.r cMeasPendingTriggerTime
tIMEAFTERTRIG GER_1000
fACHULBOTrafVolMeas. rcThreshold
tRAFFICVOLUME THR_512
Reportingthresholdforbufferoccupancyin CELL_FACH.
fACHULBOTrafVolMeas.r cTimeToTrig
tIMETOTRIGGER _0
Indicatestheperiodoftimebetweenthe timingofeventdetectionandthetimingof sendingatrafficvolumeMeasurement Report.Notethat0removesthequantity fromtheSIB. IndicateshowlongtheUEwillblockDTCH transmissionsontheRACHafterthe measurementreportistriggered.Notethat0 removesthequantityfromtheSIB. TrafficVolumeMeasurementReport TransferModeontheDCCH. InactivitytimerfromCELL_FACHto URA_PCHtransition. Indicatestheperiodoftimeduringwhichit isforbiddentosendanynewFACHtoPCH measurementreportsevenifthetriggering conditionisfulfilled. Indicatestheperiodoftimeduringwhichit isforbiddentosendanynewPCHtoFACH measurementreportsevenifthetriggering conditionisfulfilled. Averagingtimeforthebufferoccupancy measurement. Thresholdforthebufferoccupancy(bytes) abovewhicharateincreaseoftheRAB shouldbetriggered.Thisvalueshould balancethenumberofrateincreaseandthe delayuntiltheincreaseistriggered. Timehysteresisbeforethefirstbuffer occupancymeasurementistriggered. Timehysteresisbeforeaconsecutivebuffer occupancymeasurementistriggered.Sothis definestheminimumtimebetweentwo consecutiverateincreases.
fACHULBOTrafVolMeas.r cTxInterruptTime
tIMEAFTERTRIG GER_250
fACHULBOTrafVolMeas. repMode tInactFACHPCH Cell_FACHto URA_PCH tPendFACHPCH
aM_RLC 100
0to16000step 20[TTI]
2000
URA_PCHto Cell_FACH Rate Reconfiguratio nParameters
tPendPCHFACH
0to16000step 20[ms] 0to2000step20 [ms]
2000
bOAverageTimeDLDCH
200
bOthrDLDCH
0to65535[byte] 0meansdisabled
1400
bOTimeToTriggerDLDCH
0to10000step 20[ms] 0to16000step 20[ms]
bOPendingTriggerTimeDL DCH
2000
Network Services

dataRateDLDCH _8 dataRateDLDCH _32 dataRateDLDCH _64 dataRateDLDCH _128 dataRateDLDCH _384 0to30000step 100[ms]
initialRateDLDCH
dataRateDLDCH_ 384
TheinitialdownlinkdataratetakenbyDBC whenmovingfromURA_PCHto CELL_DCH.
rateAverageTimeDLDCH
Averagingtimeforthedatarate measurement. PercentageofthecurrentRABratebelow whichadataratedecreaseistriggered.The newrateisthelowestrate,whichisabove thecurrentratemeasurement.(Onlysetfor 384kbpsand128kbps) Timehysteresisbeforethefirstrate measurementeventistriggered. Timehysteresisbeforeaconsecutiverate measurementeventistriggered.Sothis definestheminimumtimebetweentwo consecutiveservicebasedratedecreases. LengthofmeasurementwindowforDL BLERcountedintransportblocks.Duetothe missingsupportofthisfeatureinsomeUEs thissettinghasnoinfluenceforthese. BLERthresholdabovewhichthedatarate willbedecreasedtothenextlowerrate.Due tothemissingsupportofthisfeaturein someUEsthissettinghasnoinfluencefor these. Theperiodoftime(countedintransport blocks)duringwhichitisforbiddentosend anynewmeasurementreportswiththesame qualitymeasurementeventidentityevenif thetriggeringconditionisfulfilled. TimeafterwhichtheUEmaybesentto URA_PCHstateincaseofinactivityonboth links(UL/DL).
relativeRateThrDLDCH
0to100[%]0 meansdisabled
rateTimeToTriggerDLDCH
0to10000step 100[ms] 0to16000step 20[ms]
ratePendingTriggerTimeD LDCH
2000
bLERWindowLength
1to512[#of TBs]
180
Datarate decrease related parameters
bLERthr
0to100[%]
10%
bLERPendingAfterTrigger
1to512[#of TBs] 0to65535 [seconds]0 meansdisabled pSRateDLDCH_ 8, pSRateDLDCH_ 32, pSRateDLDCH_ 64, pSRateDLDCH_ 128, pSRateDLDCH_ 384 0.100
480
rABInactivityTimer
minReduceRateDLDCH
pSRateDLDCH_64
TheminimumDCHdownlinkdataratefor servicetriggereddataratedowngrade.
CAC/DBC/Co nCParameters forfaultyDL powercontrol [someofthe earlyUEsdo notproperly supportDL
thrCACDL
100%
thrConCDL
0.100
100%
LoadthresholdfortheDLcalladmission control,ifDLpowercontrolisnotworking. CACisessentiallydisabledtoreliefthevery tightcapacityissues. LoadthresholdfortheDLcongestion control,ifDLpowercontrolisnotworking. ConCisessentiallydisabledtoreliefthevery tightcapacityissues.
Network Services
powercontrol] thrDBCDL 0100

LoadthresholdfortheDLdynamicbearer control,ifDLpowercontrolisnotworking. DBCisessentiallydisabledtoreliefthevery tightcapacityissues.
100%
4.3.1.9.2
Engineering Guideline
Following parameters are organized by function group and in alphabet order for easy reference and described in following fashion: Name of parameters Parameter Name in database: as seen on OMC GUI Access in OMC GUI :navigation path to locate the parameter and how this parameter is accessed (if or not the object has to be blocked) Unit & Range Granularity: network element levels this parameter can be accessed (RNC, Cell level, etc.) Description: Dependencies and constraints: is this parameter correlated to other parameters and any constraints on how this parameter value should be set. Setting Tradeoff: impact when the value is set to high and low values. Engineering Recommendation: Cingulars choice on parameter value based on latest strategy and/or field study. AccessRules RW RO ROSC RWLO RWPL RWEL RWDC Access Interface RNCCLI OMC The parameter is read-write The parameter is read-only The parameter is writable at creation then it is read-only The parameter is read-write only when the object is locked The parameter is read-write only when parent object is locked The parameter is read-write only when top-level object is locked DC = Direct Connect (parameters are adjustable via LMT, only). LMT = Local Maintenance Terminal
This means that the parameter is a local RNC parameter accessible only via CLI script. In the UMTS ParCat this corresponds to the attribute ui. The (Node B or RNC) parameter is accessible via OMC-U
MostoftheseparametersareRNCCLIaccessibleonly.Fortheseparameters,thegeneral recommendationisnottochangethemfromCingulardefaultuntilfurthernoticefromHQ.It isbelievedthatsuchparametershavebeenoptimizedusingadvancedsimulationandwork wellinnormaltrafficconditions. Furthermonitoringofnetworkperformanceandtrialswillberuntostudytheseparameters. Notificationwillbeissuedtotheaudienceofthisfieldguideforanyupdatedvalue. ThissectionisintendedtoprovideguidanceonOMCaccessibleparametersandRNCCLI parameterthataremostrelevanttonetworkperformanceandcustomerexperience.Forallthe

Network Services
otherlessimportantRNCCLIaccessibleonlyparameters,refertoparameterexcelsheetin section7.1,thisfieldguideandLucentLoadControlTAN. ItisstronglyrecommendednottomodifytheCLIonlyparametersasthesearesensitive parameterswithhighimpactonperformance.ForOMCaccessibleparameters,current recommendationsshouldbefollowedandalternationshouldbecoordinatedbyHQand Regionalleads. LoadEstimationParameters
FilterCoefficientDL
Parameter Name in database: filterCoefficientDL Access in OMC GUI: LCell Overload Control tab. RW-LO Unit & Range: cOEFF_0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 17, 19. Granularity: per Cell Description: Filter coefficient for uplink load measurements. See section 4.3.1.3. for the formula. It basically controls the weighting of current measurement in over historic sliding window average. Dependencies and constraints: Setting Tradeoff: Larger values cause the load measurements to be less sensitive to short peaks. However this also causes additional delay until the load control can react on changes. Engineering Recommendation: 6 (corresponds to 0.75 seconds filter time constant) until further trial.
FilterCoefficientUL
Parameter Name in database: filterCoefficientUL Access in OMC GUI: LCell Overload Control tab. RW-LO Unit & Range: cOEFF_0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 17, 19. Granularity: per Cell Description: Filter coefficient for uplink load measurements. See section 4.3.1.3. for the formula. It basically controls the weighting of current measurement in over historic sliding window average. Dependencies and constraints: Setting Tradeoff: Larger values cause the load measurements to be less sensitive to short peaks. However this also causes additional delay until the load control can react on changes. Engineering Recommendation: 6 (corresponds to 0.75 seconds filter time constant) until further trial.
HysteresisTime
Parameter Name in database: hysteresisTime Access in OMC GUI: LCell Overload Control tab. RW-LO Unit & Range: 1000...30 000 [ms]1000 ms step. Granularity: per Cell Description: This parameter defines the delay before measurement report is sent, after triggering condition is met. See figure 49 for illustration. Dependencies and constraints: Setting Tradeoff: higher value will cause longer delay (thus making the algorithm less sensitive and reactive) to send measurement report indicating certain load situation. Engineering Recommendation: 2000 ms until further trial.
MeasurementPeriodLong
Network Services
Parameter Name in database: measurementPeriodLong Access in OMC GUI: LCell Overload Control tab. RW-LO Unit & Range: 1 to 60 [min] with 1 minute step. Granularity: per Cell Description: Interval of periodical load measurements for the estimation of the daily_low_RSSI measurements. Dependencies and constraints: Setting Tradeoff: this is not a critical parameter. The impact of high or low values is unknown at this point. Engineering Recommendation: 15 minutes until further trial.
MeasurementReporting
Parameter Name in database: measurementReporting Access in OMC GUI: LCell Overload Control tab. RO Unit & Range: event triggered; periodic. Granularity: per Cell Description: This parameter indicates what type of measurement reporting is used.. Dependencies and constraints: n/a Setting Tradeoff:. Engineering Recommendation: In 03.01 the only possible value is event triggered.
TimeMeasureControl
Parameter Name in database: timeMeasureControl Access in OMC GUI: LCell Overload Control tab. RW-LO Unit & Range: 0...1439 [min] (corresponding to 0:00 to 23:59) Granularity: per Cell Description: defines the time when RSSI sample is taken as low RSSI value used in load control algorithm. Dependencies and constraints: Setting Tradeoff:. Engineering Recommendation: 120 (2 AM) or depends on local market RSSI measurement
AdmissionControlParameters DLCallAdmissionControlThreshold
Parameter Name in database: thrCACDL Access in OMC GUI: LCell Overload Control tab. RW Unit & Range: 0...100 [%] in step of 1 Granularity: per Cell Description: Load threshold for the DL call admission control and DL dynamic bearer control for 64k/ 128k PS service and voice. Dependencies and constraints:. Setting Tradeoff: Lower thresholds result in earlier blocking of new calls and will lower the overall system load. Engineering Recommendation: 75% until further trial
ULCallAdmissionControlThreshold
Parameter Name in database: thrCACUL

Network Services
Access in OMC GUI: LCell Overload Control tab. RW Unit & Range: 0...100 [%] in step of 1 Granularity: per Cell Description: Load threshold for the UL call admission control and UL dynamic bearer control for voice Dependencies and constraints: Due to problems with RSSI spikes during UE attaches it is recommended to turn off all UL threshold. Setting Tradeoff: Lower thresholds result in earlier blocking of new calls and will lower the overall system load. Engineering Recommendation: 100% (no admission control is needed)
CongestionControlParameters CongestionWaitTime
Parameter Name in database: conCWaitTime Access in OMC GUI: LCell Overload Control tab. RW Unit & Range: 100 to 10000 [ms] 100 ms step Granularity: per Cell Description: Setting this time allows to define the interval after which ConC is triggering a data rate decrease again if the load is still too high. If ConC has been disabled this value has no effect. Dependencies and constraints: depends on thrConCDL or thrConCUL. Setting Tradeoff: longer timer will delay reaction to congestion control. Engineering Recommendation: 2000 ms until further trial.
DLCongestionControlThreshold
Parameter Name in database: thrCongDL Access in OMC GUI: LCell Overload Control tab. RW Unit & Range: 0...100 [%] in step of 1 Granularity: per Cell Description: Load threshold for the DL congestion control Dependencies and constraints: Setting Tradeoff: Higher thresholds would result in a higher probability to reach the instability condition and therefore to deteriorate the transmission quality for all data carriers. Engineering Recommendation: 100% (no DL congestion control is needed) Lucent claims that the implementation of reducing rate has worse impact than instability problem caused by overload, and Lucent proprietary Aggregated Overload Control algorithm is effective in handling overload situation when ConC is switched off. To be validated.
ULCongestionControlThreshold
Parameter Name in database: thrCongUL Access in OMC GUI: LCell Overload Control tab. RW Unit & Range: 0...100 [%] in step of 1 Granularity: per Cell Description: Load threshold for the UL congestion control Dependencies and constraints: Setting Tradeoff: Higher thresholds would result in a higher probability to reach the instability condition and therefore to deteriorate the transmission quality for all data carriers. Engineering Recommendation: 100% (no DL congestion control is needed) Lucent claims that the implementation of reducing rate has worse impact than instability problem caused by overload, and Lucent proprietary Aggregated Overload Control algorithm is effective in handling overload situation when ConC is switched off. To be validated.
Network Services
DynamicBearerControl(DBC)Parameters DLDBCThreshold
Parameter Name in database: thrDBCDL Access in OMC GUI: LCell Overload Control tab. RW Unit & Range: 0...100 [%] in step of 1 Granularity: per Cell Description: Load threshold for the DL dynamic bearer control for 384k PS service Dependencies and constraints: Setting Tradeoff: Lower thresholds result in earlier DBC blocking and will lower the overall system load. The threshold should be a good trade-off between outage and overload for the 384k PS service. Engineering Recommendation: 50%
EcIoThreshold
Parameter Name in database: ecI0thr Access in OMC GUI: LCell Overload Control tab. RW Unit & Range: '-24.0 to 0 [dB] in step of 1 Granularity: per Cell Description: This threshold defines the coverage area in which the environment status is cell center. Only within this area DBC allows to get a 384k RAB. See figure 52 for illustration. If measured DL Ec/Io is above this threshold, the UE is considered in cell centre, and 384 kbps can be granted for DL. Otherwise, UE is considered in cell edge and 384 kbps will not be granted. Dependencies and constraints: Setting Tradeoff: Decreasing this value will extend the area where 384k calls can be initiated but will also reduce system capacity (number of users). Engineering Recommendation: -13 dB until further trial.
ULDBCThreshold
Parameter Name in database: thrDBCUL Access in OMC GUI: LCell Overload Control tab. RW Unit & Range: 0...100 [%] in step of 1 Granularity: per Cell Description: Load threshold for the UL dynamic bearer control for 64k PS service Dependencies and constraints: Setting Tradeoff: Lower thresholds result in earlier DBC blocking and will lower the overall system load Engineering Recommendation: 100% (disabled, due to concerns for high power spikes when UE attaches to the network).
StateTransitionParameters StateTransitionControl DirectDCHtoPCHtransition

Parameter Name in database: stateTrans.directDCHPCH Access in OMC GUI: RNC CLI only in stateTrans object. RW Unit & Range: TRUE, FALSE Granularity: per RNC
Network Services
Description: Direct transition from CELL_DCH to URA_PCH. TRUE means the UE will move directly to URA_PCH, FALSE means the UE will go first to CELL_FACH. Dependencies and constraints: Setting Tradeoff: if enabled, DCH resource will be occupied when UE transit from PCH even for low speed need. CELL FACH is better option. Engineering Recommendation: FALSE.
DirectPCHtoDCHtransition
Parameter Name in database: stateTrans.directDCHPCH Access in OMC GUI: RNC CLI only in stateTrans object. RW Unit & Range: TRUE, FALSE Granularity: per RNC Description: Direct transition from URA_PCH to CELL_DCH. TRUE means the UE will move directly to CELL_DCH, FALSE means the UE will go first to CELL_FACH. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: FALSE.
RACH/FACHCongestion FACHcongestionthreshold
Parameter Name in database: fACHCongThresh Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 Granularity: per RNC Description: Threshold for determining if a Cell's FACH channel is in a congested state. Performance counter PercentFACHOccupancy provides a readout of this metric Dependencies and constraints: Setting Tradeoff:. Engineering Recommendation: 90.
RACHcongestionthreshold
Parameter Name in database: rACHCongThresh Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 8 Granularity: per RNC Description: Threshold for determining if a Cell's RACH channel is in a congested state. The RNC simply compares the RACH persistency against this threshold. Counter RACHcongestion provides a readout of this metric. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2.
CellDCHtoFACHtransition AverageTimeDLDCHtoFACHdataratemeasurement
Parameter Name in database: avTimeRDLDCHFACH
Network Services
Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 10 000 [ms] in step of 1 Granularity: per RNC Description: Averaging period for DL rate measurement in CELL_DCH. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 3000 ms.
AverageTimeULDCHtoFACHdataratemeasurement
Parameter Name in database: avTimeRULDCHFACH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 10 000 [ms] in step of 1 Granularity: per RNC Description: Averaging period for UL rate measurement in CELL_DCH. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 3000 ms.
BufferOccupancythresholdforDLDCHtoFACHtransition
Parameter Name in database: bOthDLDCHFACH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 65535 [byte]] in step of 1 Granularity: per RNC Description: Threshold for unfiltered downlink buffer occupancy being below this value before transition from CELL_DCH to CELL_FACH. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 125 bytes.
NumberofSamplesindataratemeasurementaveragingforDCHtoFACHtransition
Parameter Name in database: nSampRateDCHFACHDataRate Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 1 000 ms in step of 10 ms Granularity: per RNC Description: Parameter defines the granularity of the Uplink and downlink data rate moving average filter in CELL_DCH for determining CELL_DCH to CELL_FACH transition. RNC will take data measurement at each interval defined by this parameter; then a running filtering window (governed by the filtering function described in section 4.3.1.3) is used to calculate data rate samples at all these intervals. Then RNC will simply take average of all the samples within window defined by avTimeRULDCHFACH or avTimeRDLDCHFACH to obtain UL or DL data rate measurement respectively. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 12 (120 ms)
RatethresholdforDLDCHtoFACHtransitionwithClearFACH
Network Services
Parameter Name in database: rthClearDLDCHFACH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 000 [bps] in step of 1 Granularity: per RNC Description: Downlink data rate threshold for CELL_DCH to CELL FACH transition when the FACH is not in congested state. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2500 bps.
RatethresholdforULDCHtoFACHtransitionwithClearRACH
Parameter Name in database: rthClearULDCHFACH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 000 [bps] in step of 1 Granularity: per RNC Description: uplink data rate threshold for CELL_DCH to CELL FACH transition when the RACH is not in congested state. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2500 bps.
RatethresholdforDLDCHtoFACHtransitionwithcongestedFACH
Parameter Name in database: rthConDLDCHFACH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 000 [bps] in step of 1 Granularity: per RNC Description: Downlink data rate threshold for CELL_DCH to CELL FACH transition when the FACH is in congested state. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2000 bps.
RatethresholdforULDCHtoFACHtransitionwithcongestedRACH
Parameter Name in database: rthConULDCHFACH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 000 [bps] in step of 1 Granularity: per RNC Description: uplink data rate threshold for CELL_DCH to CELL FACH transition when the RACH is in congested state. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2000 bps.
TimePendingfornewDCHtoFACHtransition
Parameter Name in database: tPendDCHFACH Access in OMC GUI: RNC CLI only. RW
Network Services
Unit & Range: 0 to 16000 step 20 [ms] Granularity: per RNC Description: Indicates the period of time during which it is forbidden to send any new DCH to FACH measurement reports even if the triggering condition is fulfilled. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2000 ms
TimeToTriggerforDCHtoFACHtransition
Parameter Name in database: tTrigDCHFACH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 10 000 step 100[ms] Granularity: per RNC Description: The period of time between the timing of event detection and the timing of triggering the DCH to FACH measurement report for all criteria being satisfied. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2000 ms
CellFAHtoDCHtransition(RNCtriggered) AveragePeriodDLBOmeasurementforFACHtoDCHtransition
Parameter Name in database: avTimeBODLFACHDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 10 000 [ms] in step of 1 Granularity: per RNC Description: Average period for DL buffer occupancy measurement in CELL_FACH. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 200 ms.
AveragePeriodDLdataratemeasurementforFACHtoDCHtransition
Parameter Name in database: avTimeRDLFACHDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 000 [ms] in step of 1000ms Granularity: per RNC Description: Average period for DL data rate measurement in CELL_FACH. RNC will take data measurement at each interval defined by nSampRateFACHDCHDataRate; then a running filtering window (governed by the filtering function described in section 4.3.1.3) is used to calculate data rate samples at all these intervals. Then RNC will simply take average of all the samples within window defined by avTimeRDLFACHDCH to obtain DL data rate measurement respectively Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 10000 ms.
Network Services
AveragePeriodULDataRatemeasurementforFACHtoDCHtransition
Parameter Name in database: avTimeRULFACHDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 000 [ms] in step of 1000 ms Granularity: per RNC Description: Average period for UL data rate measurement in CELL_FACH. RNC will take data measurement at each interval defined by nSampRateFACHDCHDataRate; then a running filtering window (governed by the filtering function described in section 4.3.1.3) is used to calculate data rate samples at all these intervals. Then RNC will simply take average of all the samples within window defined by avTimeRULFACHDCH to obtain UL data rate measurement respectively Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 10000 ms.
BufferOccupancythresholdforDLFACHtoDCHtransition
Parameter Name in database: bOthDLFACHDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 65535 [byte]] in step of 1 Granularity: per RNC Description: Downlink buffer occupancy threshold for transitioning from CELL_FACH to CELL_DCH. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 500 bytes.
BufferOccupancymultiplierforDLFACHtoDCHtransition
Parameter Name in database: dCCHBuffOccupancy Multiplier Access in OMC GUI: RNC CLI only. RW Unit & Range: Granularity: per RNC Description: Parameter defines a scaling on the DCCH for buffer occupancy trigger from CELL_FACH to CELL_DCH. The formula used to calculate BO is : Downlink Buffer Occupancy=DTCH Buffer Occupancy + dCCHBuffOccupancyMultiplier *(DCCH Buffer Occupancy) A setting of 1.0 means that the buffer occupancy is the sum of DCCH and DTCH buffer occupancy. A setting of 0.0 means that the buffer occupancy is purely the DTCH buffer occupancy. A setting of > 1 means that the DCCH buffer occupancy has a higher weighting than the DTCH. Parameter will only be updated by RNC following RNC reset. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 1.
NumberofSamplesindataratemeasurementaveragingforFACHtoDCHtransition
Parameter Name in database: nSampRateFACHDCHDataRate Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 1 000 ms in step of 10 ms
Network Services
Granularity: per RNC Description: Parameter defines the granularity of the Uplink and downlink data rate moving average filter in CELL_FACH for determining CELL_FACH to CELL_DCH transition. RNC will take data measurement at each interval defined by this parameter; then a running filtering window (governed by the filtering function described in section 4.3.1.3) is used to calculate data rate samples at all these intervals. Then RNC will simply take average of all the samples within window defined by avTimeRULFACHDCH or avTimeRDLFACHDCH to obtain UL or DL data rate measurement respectively Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 12 (120 ms)
RatethresholdforDLFACHtoDCHtransition
Parameter Name in database: rthDLFACHDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 000 [bps] in step of 1 Granularity: per RNC Description: Downlink data rate threshold for CELL_DCH to CELL FACH transition Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 3000 bps.
RatethresholdforULFACHtoDCHtransition
Parameter Name in database: rthULFACHDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 000 [bps] in step of 1 Granularity: per RNC Description: uplink data rate threshold for CELL_FACH to CELL DCH transition Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 3000 bps.
TimePendingfornewFACHtoDCHtransition
Parameter Name in database: tPendFACHDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 16000 step 20 [ms] Granularity: per RNC Description: Indicates the period of time during which it is forbidden to send any new FACH to DCH measurement reports even if the triggering condition is fulfilled. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2000 ms
TimeToTriggerforFACHtoDCHtransition
Parameter Name in database: tTrigDCHFACH
Network Services
Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 10 000 step 100[ms] Granularity: per RNC Description: The period of time between the timing of event detection and the timing of triggering the FACH to DCH measurement report for data rate measurements. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 1000 ms
TimeToTriggerforDCHtoFACHtransitionusingBO
Parameter Name in database: tTrigBOFACHDC Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 10 000 step 100[ms] Granularity: per RNC Description: The period of time between the timing of event detection and the timing of triggering the FACH to DCH measurement report for buffer occupancy measurements. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 0 ms
CellFAHtoDCHtransition(RNCtriggered) BOthresholdforULFACHtoDCHtransition
Parameter Name in database: fACHULBOTrafVolMeas.rcThreshold Access in OMC GUI: RNC CLI only. RW Unit & Range: tRAFFICVOLUMETHR_8, 16, ...1024, 2K, 3K, ....384K, 512K, 768K Granularity: per RNC Description: Reporting threshold for buffer occupancy in CELL_FACH. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: tRAFFICVOLUMETHR_512 K
TimePendingfornewFACHtoDCHtransitionusingULBOmeasurement
Parameter Name in database: fACHULBOTrafVolMeas.rcMeasPendingTriggerTime Access in OMC GUI: RNC CLI only. RW Unit & Range: tIMEAFTERTRIGGER_0, 250, 500, 1000, 2000, 4000, 8000, 16000 ms Granularity: per RNC Description: Indicates the period of time during which it is forbidden to send any new measurement reports with the same TrafficVolume event identity even if the triggering condition is fulfilled. Note that 0 removes the quantity from the SIB. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: tIMEAFTERTRIGGER_1000 (1000 ms)
TimeToTriggerforFACHtoDCHtransitionusingULBOmeasurement
Parameter Name in database: fACHULBOTrafVolMeas.rcTimeToTrig Access in OMC GUI: RNC CLI only. RW
Network Services
Unit & Range: tIMETOTRIGGER_0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 ms Granularity: per RNC Description: The period of time between the timing of event detection and the timing of triggering the FACH to DCH measurement report for data rate measurements. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: tIMEAFTERTRIGGER_1000 (1000 ms)
CellFAHtoURA_PCHtransitionandURA_PCHtoCELLFACHtransition InactivityTimerforCELL_FACHtoURA_PCHtransition
Parameter Name in database: tInactFACHPCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 1000 [s] in step of 1 Granularity: per RNC Description: Inactivity timer from CELL_FACH to URA_PCH transition. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 100 s
TimependingfornewCELL_FACHtoURA_PCHtransition
Parameter Name in database: tInactFACHPCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 16000 step 20 [TTI] Granularity: per RNC Description: Indicates the period of time during which it is forbidden to send any new FACH to PCH measurement reports for the same connection even if the triggering condition is fulfilled. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2000 TTI
TimependingfornewCELL_FACHtoURA_PCHtransition
Parameter Name in database: tPendPCHFACH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 16000 step 20 [TTI] Granularity: per RNC Description: Indicates the period of time during which it is forbidden to send any new URA_PCH to CELL_FACH measurement reports for the same connection even if the triggering condition is fulfilled. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2000 TTI
DataRateAdaptationParameters
AverageTimeforDataRatemeasurement
Network Services
Parameter Name in database: rateAverageTimeDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 30000 step 100 [ms] Granularity: per RNC Description: Averaging time for the data rate measurement. 0 means no averaging is performed. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 0 ms
BOAverageTimeDLDCH
Parameter Name in database: bOAverageTimeDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 2000 step 20 [ms] Granularity: per RNC Description: Averaging time for the buffer occupancy measurement. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 200 ms
BOthresholdforDLDCHrateincrease
Parameter Name in database: bOthrDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 65535 [byte] 0 means disabled Granularity: per RNC Description: Threshold for the buffer occupancy (bytes) above which a rate-increase of the RAB should be triggered. This value should balance the number of rate increase and the delay until the increase is triggered. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 1400 bytes
BOTimeToTriggerforDLDCHrateincrease
Parameter Name in database: bOTimeToTriggerDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 10000 step 20 [ms] Granularity: per RNC Description: Time hysteresis before the first buffer occupancy measurement is triggered. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 0 ms
BOPendingtimetotriggerfornewDLDCHrateincrease
Parameter Name in database: bOPendingTriggerTimeDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 16000 step 20 [ms] Granularity: per RNC
Network Services
Description: Time hysteresis before a consecutive buffer occupancy measurement is triggered. So this defines the minimum time between two consecutive rate increases. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2000 ms
BLERWindowLengthforDLBLERmeasurement
Parameter Name in database: bLERWindowLength Access in OMC GUI: RNC CLI only. RW Unit & Range: 1 to 512 [# of TBs] Granularity: per RNC Description: Length of measurement window for DL BLER counted in transport blocks. Due to the missing support of this feature in some UEs this setting has no influence for these. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 180
BLERThresholdforDLDCHDataRatedecrease
Parameter Name in database: bLERthr Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 [%] Granularity: per RNC Description: BLER threshold above which the data rate will be decreased to the next lower rate. Due to the missing support of this feature in some UEs this setting has no influence for these. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 10%
BLERPendingTimeforDLDCHDataRatedecrease
Parameter Name in database: bLERPendingAfterTrigger Access in OMC GUI: RNC CLI only. RW Unit & Range: 1 to 512 [# of TBs] Granularity: per RNC Description: The period of time (counted in transport blocks) during which it is forbidden to send any new measurement reports with the same quality measurement event identity even if the triggering condition is fulfilled. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 480
DataRateRelativeThresholdtotriggerDLDCHratedecrease
Parameter Name in database: relativeRateThrDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 [%] 0 means disabled Granularity: per RNC
Network Services
Description: Percentage of the current RAB rate below which a data rate decrease is triggered. The new rate is the lowest rate, which is above the current rate measurement. (Only set for 384kbps and 128kbps). Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 0
InactivityTimerofRABtotriggerDCHtoURA_PCHtransition
Parameter Name in database: rABInactivityTimer Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 65535 [seconds] 0 means disabled Granularity: per RNC Description: Time after which the UE may be sent to URA_PCH state in case of inactivity on both links (UL/DL). Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 5
InitialDLDCHDataRate
Parameter Name in database: initialRateDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: dataRateDLDCH_8, dataRateDLDCH_32, dataRateDLDCH_64. dataRateDLDCH_128. dataRateDLDCH_384 Granularity: per RNC Description: When the UE moves out of CELL_FACH (or URA_PCH in case CELL_FACH is disabled) state first the data rate defined by this parameter assigned. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: dataRateDLDCH_384. This is in order to reduce the amount of signalling overhead on the RNC and to get to the initial rate as quickly as possible
MinimumDLDCHallowedinDataRatedecrease
Parameter Name in database: minReduceRateDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: pSRateDLDCH_8, pSRateDLDCH_32, pSRateDLDCH_64, pSRateDLDCH_128, pSRateDLDCH_384 Granularity: per RNC Description: The minimum DCH downlink data rate for service triggered data rate downgrade. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: pSRateDLDCH_64
TimetoTriggerforDLDCHDataRateDecrease
Parameter Name in database: rateTimeToTriggerDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 10000 step 100 [ms] Granularity: per RNC
Network Services
Description: Time hysteresis before the first internal rate measurement event is triggered which will lead to data rate decrease Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 0 ms
Network Services
4.3.2
4.3.2.1
Power Control
Cingular Strategy Power control should be utilized efficiently to provide the as low power as possible to UEs, as accepted by quality requirement. This is to achieve maximized capacity in both DL and UL. At early stage of UMTS network launch, there might not be much demand from capacity perspective thus less stringent requirement on optimization of power control parameters. Also Lucent has made vast majority of Power Control parameters accessible through RNC CLI interface only, discouraging operator to make changes on these semi-fixed parameters. Thus it is recommended not to modify these CLI parameters by market. Significant performance issues that believed to relate to Power Control should be communicated to HQ staff at earliest convenience. Unless there is joint decision made by HQ and Lucent, the values recommended in engineering guidelines section should not be altered. For the ones that are accessible through OMC also (power settings on common control channels), it is possible to optimize them based on individual cell needs. Nevertheless, such optimization should be managed cautiously.
4.3.2.2
Overview
RF power control is very important to the WCDMA system (which is a 1/1 reuse frequency system), particularly in uplink direction as the power level that is received from each mobile device must be approximately the same power level as the signals received from other mobile devices. If one mobile device were received at a much higher power level than the other devices, the reception of the lower power channels would be lost in the interference and noise. As a result, more accuracy in power level control can results in received signals of the same level. This results in higher levels of system capacity (more customers can simultaneously operate on the same channel). See the figure below as an example: S
BS
MS2 MS1 If the power of MS1 is not properly controlled it will jam the weaker signal of MS2
Figure 57: Power Control Illustration In the example, considering MS2 is located much further from the BS than MS1, and both MSs are transmitting the same power on the same frequency, the BS would very see good C/I from MS1, but very poor C/I from MS2. In other words, MS1 is interfering MS2 and in fact all other users which are further away from the BS. It simply doesn't work.
Network Services
RF power control is a process of adjusting the power level of a mobile radio as it moves closer to and further away from a transmitter. RF power control is typically accomplished by the sensing the received signal strength level and the relaying of power control messages from a transmitter to the mobile device with commands that are used to increase or decrease the mobile device's output power level. To accurately control the RF power level, The WCDMA RF channel uses a combination of coarse (open loop) power control and precise (closed loop) power control. Open loop power control is a process of controlling the transmission power level for a mobile device using the received power level and an indicator to how much RF power it should transmit. As the received signal level goes down, the transmitter signal level is increased. Open loop power control provides for relatively broad (wide range) power level control. It consists of PRACH power setting for RACH procedure, initial power setting for UL DPCCH and DL DPCH. Closed loop power control is a process of controlling the transmission power level for the mobile device using the power level control commands that are received from another transmitter that is receiving its signal (the closed loop). Closed loop power control in the WCDMA system is used to precisely control (fine tune) the mobile device transmitter level. When in closed loop operation (when the mobile device is assigned to a specific channel), the base station sends power level control commands 1,500 times per second (every 666 sec). The power control commands can change the output power in 1, 2 or 3 dB steps. The same closed-loop power control technique is also used on downlink, though here the motivation is different: on the downlink there is no near-far problem due to the one-to-many scenario. All the signals within one cell originate from the one base station to all mobiles. It is, however, desirable to provide a marginal amount of additional power to mobile stations at the cell edge, as they suffer from increased othercell interference. Also on the downlink a method of enhancing weak signals caused by Rayleigh fading with additional power is needed at low speeds when other error correcting methods based on interleaving and error correcting codes do not yet work effectively. Power control is implemented in the Downlink Dedicated Channels, Downlink Common Channels, Uplink Dedicated Channels, and Uplink Common Channels. At radio link establishment, the transmit power level is estimated without any information from the counter part. This procedure is known as open loop power control. Once a link is established, the power is continuously optimized using a loop including the UE, Node B, and RNC. This is the closed loop procedure and it is split into two sub-control loops, the inner loop and the outer loop. Following chart illustrates the function split of Power control
Table 24 Function of Power Control 4.3.2.3 DPCCH and DPDCH Overview
In order to understand the mechanism of power control in downlink and uplink, one needs to understand the structure of DPCCH (dedicated physical control channel) and DPDCH (dedicated physical data channel) in DL and UL, as these two channels are mapped differently in DL and UL therefore the handling of the power of each is different in Power Control. Figure below illustrates the frame structure of both physical channels in Uplink, where DPCCH and DPDCH are separated and transmitted simultaneously.
Network Services
Figure 58 UL DPCH (DPCCH and DPDCH) Figure 4.28 illustrates the frame structure of Downlink DPCH (Downlink Physical Channel), in which DPCCH and DPDCH are multiplexed.
Figure 59 DL DPCH (DPDCH+DPCCH) Therefore, in Uplink the power control of DPCH is different from downlink. In Uplink, DPCCH power is determined by algorithm (detailed in following sections) and corresponding DPDCH power is determined then by Gain factors (Bc and Bd, which can vary based on Transport Format Combination, TFC, for different type of transport channel). In Downlink, NodeB determines the appropriate Power for DL DPDCH and using 3 power offset (PO1, PO2, PO3, which defines the relative difference between DPDCH and TFCI bits, TPC bits, Pilot bits of DPCCH) to determine the power of DPCCH in downlink.
4.3.2.4
Open Loop Power Control
Network Services
Since the uplink and downlink frequencies of WCDMA are within the same frequency band, a significant correlation exists between the average path loss of the two links. This makes it possible for each UE, before accessing the network and for each base station when the radio link is set up, to estimate the initial transmit powers needed in UL and DL based on the path loss calculations in the downlink direction. This function, is denoted as open-loop PC. In Uplink, Open loop power control is used to determine:1) initial power of PRACH preamble and message part; and 2) initial power setting of uplink dedicated channel (DPCCH) before Closed Loop (to be more precise, Inner Loop PC) starts. In Downlink, open loop power control is used to determine the initial power setting of Downlink DPCCH to start the Inner Loop PC. The corresponding power setting of corresponding DPDCH is determined by fixed power offset PO1, PO2 and PO3. Following figure illustrates the usage of the open loop pc:
PRACH power Decided by UL Open loop PC
Decided by UL Open loop

Decided by DL Open loop PC
DCCH (logical channel) is mapped to DCH transport channel DCH is then mapped to DPCCH/DPDCH physical channels
Figure 60 Use Open Loop PC for initial power of DL/UL DPCCH 4.3.2.5 UL Open Loop Power Control PRACH preamble & message part power determination This has been explained in section 4.2.2.1.2.
4.3.2.5.1
4.3.2.5.2
UL Initial DPCCH Tx power
The UE determines the initial power of the UL DPCCH by the following procedure: 1. Acquire the DPCCH power offset parameter from the received RRC messages, for example the RRC CONNECTION SETUP message. 2. Measure the CPICH RSCP of the required Node B. 3. Calculate the UL DPCCH initial power using the following equation:
DPCCH initial transmission power = DPCCH PowerOffset(dB) CPICH RSCP(dBm)

3GPP spec. allows DPCCH power offset to be determined by certain formula using SIR, UL interference, SF and CPICH power. In Lucent, it is configured through parameter dPCCHPowerOffset which is only accessible through RNC CLI. The default is -84 dB. Following figure shows the settings of parameters used for UL PC:
Network Services
Figure 61 UL PC information in DL CCCH The UE transmits the first DPCCH with the calculated power. The DPCCH power offset is set by RNC office data regardless of the distance between the UE and the Node B while the CPICH RSCP measured at the UE may vary. For this reason, the DPCCH initial power of a UE located at the cell edge tends to be higher than that of a UE located close to the Node B. During the call set-up phase, a Power Control Preamble can be used to make sure that the inner loop power control has converged before the actual start of the data transmission. This uplink DPCCH power control preamble is a period of N uplink DPCCH radio frames transmitted prior to the start of the uplink DPDCH. The length N of the power control preamble is a UE-specific parameter signaled by the RNC and can take the values between 0 and 7 radio frames (0 70 ms). In Lucent, it is configured by RNC CLI only parameter pCPreamble, default at 7 ,as seen in figure above. (For more information on this function, see 25.214 section 5.1.2.4. ) Within this 7 frame period (70ms), no DPDCH is transmitted. The change in uplink DPCCH transmit power shall be given by:
DPCCH = TPC TPC_cmd.

Where TPC_cmd is determined by UE according to power control Algorithm 1 based on processed TPC command over every time slots. This is described in 25.214. 5.1.2.2.1. TPC is controlled by parameter tPCStepSizeUL, default is 1 dB. As seen on the above figure (algorithm1: 1dB). Inner loop Power control will start after preamble period is over. 4.3.2.6 DL Open Loop Power Control (DL DPCH Initial Tx Power)
In Downlink, Open Loop Power control is responsible of calculating the initial Tx power of DL DPDCH and DPCCH. Then Inner loop power control will start afterward. In Downlink, DPCCH and DPDCH are time multiplexed on DPCH. RNC will first determine the power of DPDCH with following procedure and formula, then DL DPCCH power are calculated based on Power Offsets (PO1, PO2, PO3).
4.3.2.6.1
DL DPCH Initial Tx Power at Call Setup
1. The RNC determines the initial power of the DL DPDCH (relative power in dB to CPICH power) by the following procedure: Acquire the CPICH Ec/N0 measurement results from the UE via the RRC Connection Request message.
Network Services
Calculate the DL DPDCH initial power using the following equation, then send NodeB the calculated initial power in an NBAP message, for example the RL SETUP REQUEST message.
P DPDCH initial = EcNoTarget - CPICH_Ec /No + DL_POWER_MARGIN

where
P DPDCH initial specifies the relative power difference (in dB) to CPICH power, for DPDCH.
EcNoTarget is referred to the considered radio bearer configuration and expressed in dB. This is dependent on radio bearer type (i.e. UEGTFCS) as SIRtarget would be different due to that spreading factor is different for different bearer thus the processing gain varies. This is a RNC CLI only parameters. DL_Power_Margin is a parameter defined by RNC CLI parameter dLPowerMargin and also varies by radio bearer. CPICH Ec/No: is measured by UE (see figure above) 2. RNC calculate DL DPCCH power using following POs as shown in following figure:
Figure 62 Power Offset between DL DPDCH and DL DPCCH As shown above, PO1 is offset between power of TFCI (Transport Format Combination Indicator) bits and DPDCH; PO2 is power offset between TPC (Transmit Power Control) bits and DPDCH; PO3 is the power offset between Pilot bits and DPDCH. The initial power should be within the range between the maximum (Pmax) and minimum (Pmin) transmit powers set by RNC. Pmax is configured by RNC CLI parameter maxDLPower and Pmin by minDLPower. 3gpp spec. has specified that the delta between these two must be more than 18 dB. In Lucent 03.01, both parameters are dependent on radio bearers. PO1 and PO3 can not be modified once the radio link is setup. PO2 can be modified only through DCH framing protocol. These are defined by RNC CLI parameters PO1, PO2ForOneRLSet, PO2ForTwoRLSet, PO2ForThreeRFSetAndMore, PO3 respectively. Lucent has claimed that Experience with IS95 networks showed that the radio link quality is substantially enhanced when the power offset between the data and the TPC parts of the downlink frame increases with the number of radio link sets connected to the UE. The same strategy has been ported to the UMTS context. Thus, 3 parameters are available for PO2:
Network Services
PO2ForOneRLSet when the number of Radio Link Active Sets is equal to 1: default = 0 dB PO2ForTwoRLSet when the number of Radio Link Active Sets is equal to 2: default = 3dB PO2ForThreeRFSetAndMore when the number of Radio Link Active Sets is equal to 3 and more: default = 6 dB.
PO1 default is 0 dB and PO3 default is 2 dB. 4.3.2.6.2 DL DPCH Initial Tx Power in Cell_DCH mode
When the RNC adds a new radio link to existing ones (i.e. UE in Cell_DCH state moves into soft/softer handover mode), the NodeB transmit power is calculated as follows: Initial DL TX Power = PMin + Pnew_leg_offset Where: PMin is the minimum downlink transmit power allowed at the NodeB for the considered UE, same as described before. Pnew_leg_offset is an offset value defined by RNC CLI parameter newLegPowerOffset, which is bearer dependent.
4.3.2.7 4.3.2.7.1
DL Closed Loop Power Control DL Inner Loop Power Control
In DL Inner loop power control, UE will estimate the DL SIR based CPICH and compare them to the target SIR sent from NodeB. If estimated is greater than target, UE transmit a TPC command down to NodeB, otherwise, the UE transmits a TPC command up. Since DPCCH and DPDCH are time multiplexed on the DPCH when transmitted over the radio interface in the downlink, an increase or decrease of the DPCH power affects both the DPCCH and DPDCH. How UE estimate the DL SIR is UE proprietary thus beyond the scope of this documents and not further discussed. Following figure illustrates the operation sequence in DL inner loop PC:
Network Services
Figure 63 operation sequence in DL inner loop PC The rate of these commands is up to 1500 Hz. This is controlled by a parameter called DPCMode (RNC CLI parameter). 3gpp spec has defined two possible values of this parameter: 1) single TPC meaning UE sends a unique TPC command in each slot, which result in 1500 TPC per second (there are 15 slots over 10 ms Radio frame 15/10 ms = 1500 hz); or 2) TPC Triplet meaning UE repeats the same TPC commands over 3 slots, which result in TPC frequency of 500hz. In Lucent, only SingleTPC method is used. This can be seen in RRC Connection Setup message. According to the information included in the TPC command, the NodeB decides to either increase or decrease its transmit power. Irrespective of the TPC commands the NodeB transmit power must remain within power ranges defined by [Pmin ; Pmax]. If SIRest >= SIR target Then TPC command = "0" [requesting a NodeB transmit power decrease] Else TPC command = "1" [requesting a NodeB transmit power increase] In case of SHO mode, UE will measure the SIR of all downlink branches and compare them to the SIR target: If all are below SIR target, UE generates a TPC = 1 If one ore more measured SIR exceeds SIR target, UE generates a TPC = 0
All cells involved in Soft/Softer HO will receive this single TPC command and increase or decrease power together according to their individual Power Control step size. Then DPDCH power will be adjusted according to following formula:
DPDCH = TPC if TPC command = 1 DPDCH = - TPC if TPC command = 0 TPC is defined by RNC CLI parameter tPCStepSize. Default is 1 dB.
Lucent also implements Downlink Limited Power Increase technique available from spec (25.214), that limits the increased speed of the inner power control loop for Non-Real-Time (NRT) packet data transmission, which will potentially limit variations in the power level that would degrade the quality of Real Time (RT) connections. Therefore, this function is defined per RAB type and only NRT RAB will employ such technique. There are 3 parameters related to this technique: limitDLPowerincrease: enable or disable this technique. Per RAB configured. powerRaiseLimit: used to limit power increase (with complicated formula) dLPowerAvWindowSize: if power increase limit is activated, power adjustments will follow regular algorithm presented above for (dLPowerAvWindowSize 1) adjustments. After that, power
Network Services
increase limit effect will kick in. see section 4.4.3.3 in Customer_UMTS_RF_TAN_U03.01_Power_Control for further details.
4.3.2.7.2
DL Outer Loop Power Control
The downlink Outer Loop Power Control is in charge of updating the SIRtarget in order to provide the Block Error Rate performances corresponding to the requested Quality of Service. This control loop runs autonomously in the UE with a maximum speed of 100Hz. From this provided BLER value the UE derives the initial SIRtarget value. The instant BLER is continuously monitored and the SIRtarget is re-adjusted in order to ensure the requested quality is achieved in any radio channel scenario (speed, environment, etc.). The method on how to set SIRtarget in order to provide the requested BLER is not specified in the 3GPP standard. The algorithm is specific to the terminal manufacturers. In Lucent, UTRAN provides the BLER target then UE will translate them into SIRtarget for outer loop DL power control. The BLER targets are set per Dedicated Transport Channel instance which are associated with different RABs. The target is sent by the RNC to the UE via RRC signaling (RAB setup), using the downlink dedicated control channel (DCCH). See following screenshot for example:
Such BLER target is configurable through RNC CLI parameter bLERQualityTarget and broadcast in RRC system message. The formula to translate these seen values in RRC messages to real BLER target values is: BLER target Value % = 100 * 10
parameter value
E.x.: -2.1 parameter value shown above means BLER target = 100 * 10 -2.1 = 0.7 %. This is typical value for Voice call (AMR 12.2 kbps CS RAB).
4.3.2.8 4.3.2.8.1
UL Closed Loop Power Control UL Inner Loop Power
The uplink inner-loop power control is used to set the power of the uplink DPDCH and DPCCH. The base station receives the target SIR from the uplink outer-loop PC located in the RNC and compares it with the estimated SIR on the pilot symbol of the uplink DPCCH with speed at 1500 Hz or 300 Hz (controlled by parameter powerControlAlgorithm, default is algorithm 1 meaning 1500 Hz). If the received SIR is greater than the target, the base station transmits a TPC command = 0 meaning reduce power to the UE on the downlink DPCCH. If the received SIR is below the target, a TPC command = 1 meaning increase power is sent. Figure below illustrates the operational sequence of inner loop power control in UL:
Network Services
Figure 64 inner loop power control in UL
Based on the SIRest, the NodeB generates TPC commands according to the following rule: If SIRest >= SIRtarget Then TPC command = "0" [requesting a power decrease from the UE] Else TPC command = "1" [requesting an increase of the power at the UE] Then based on the TPC command values and if not UE is in Soft / softer handover mode, the UL inner power control algorithm functions as illustrated in following figure:
Figure 65 UL inner power control
Network Services
Follow are detailed descriptions of this diagram: TPC command is generated per Time Slot. Since one time slot last 10/15 = 0.667 ms, inner loop PC is quite effective in compensating the signal fluctuation (Rayleigh fading) caused by multipath environment, especially for UE speed less than 80km/h (at higher speed, inner loop PC can no longer track the change of RF signals thus losing effectiveness). To interpret TPC commands sent down by NodeB, UE has two options of algorithm: Algorithm 1 and Algorithm 2, specified by 3GPP spec (25.214). Algorithm 1 is used when the UE speed is sufficiently low to compensate for the fading of the channel. The PC step size is set by RNP to 1 or 2 dB. Algorithm 2 was designed for emulating the effect of using a PC step size smaller than 1 dB and can be used to compensate for the slow fading trend of the propagation channel rather than rapid fluctuations. It performs better than Algorithm 1 when the UE moves faster than 80 km/h or slower than 3 km/h. In Algorithm 2 the PC step size is fixed at 1 dB. The UE does not change its transmission power until it has received five consecutive TPC commands. For more details on algorithm 2, see 25.214. In Lucent, algorithm 1 is recommended (parameter powerControlAlgorithm). This setting is communicated to UE through RRC signaling messages such like RRC Connection setup (see figure in 4.3.2.6.2 for example). The TPC step size is defaulted as 1 dB but could be changed through RNC CLI parameter tPCStepSizeUL. This parameter is denoted as TPC in figure above. So
DPDCH = TCP_cmd = either 1 or -1 dB.

When algorithm 1 is used and in case UE is in Soft HO mode, i.e. multiple links exist between UE and a few NodeBs, UE receives TPC commands from multiple cells. The TPC commands of the same slots received from all the involved NodeB are combined using following function to derive the amount of power increase or decrease. Unless all TPC commands from all links are indicating 1 (power increase), UE will power down using algorithm describe below. First, the UE shall conduct a soft symbol decision Wi on each of the power control commands TPCi, where i = 1, 2, , N, where N is greater than 1 and is the number of TPC commands from radio links of different radio link sets. Finally, the UE derives a combined TPC command, called TPC_cmd, as a function of all the N soft symbol decisions Wi: TPC_cmd = (W1, W2, WN), where TPC_cmd can take the values 1 or -1.
The function shall fulfill the following criteria: If the N TPCi commands are random and uncorrelated, with equal probability of being transmitted as "0" or "1", the probability that the output of is equal to 1 shall be greater than or equal to 1/(2N), and the probability that the output of is equal to -1 shall be greater than or equal to 0.5. This rule means that, regardless of the value of N, the probability of having power decrease is always greater than the probability of having power increase. For instance, if N equals 2, then the probability of power increase is equal to 1/2N=1/4=0.25 that is still less than 0.5.
Network Services
Further, the output of shall equal 1 if the TPC commands from all the radio link sets are reliably "1", and the output of shall equal 1 if a TPC command from any of the radio link sets is reliably "0". In case of softer handover, UE receive TPC commands from multiple cell of same NodeB. In such case, all cells are required to send same TPC command. UE will simply combine them into one TPC command using same algorithm described above. The transmit power after change may not exceed the lower value between the maximum UE power according to its power class and the maximum power defined by RNC CLI parameter maxULDPCHPower. In case of Soft HO, the maximum transmit power for the UE should be the minimum value of this parameter of all Cells in the active set. This calculation is done at call setup, new link addition and deletion. The minimum transmit power can not be set by network and is specified by 25.101. the requirement is it shall be less than -50 dBm. Once DPDCH power is determined, DPCCH power can be calculated using the corresponding Gain factor c and d. These two factors vary by bearer type and TFC, and are configured by RNC CLI parameters gainFactoBc, gainFactorBd, referenceTFC, and gainFactorType. The rule is 2 one of them shall be 15 and the power ration between DPDCH and DPCCH is (d/c) . for more information, see section 6.4.5. in Customer_UMTS_RF_TAN_U03.01_Power_Control
4.3.2.8.2
UL Outer Loop Power Control
The uplink Outer Loop Power Control is in charge of updating the SIRtarget in the NodeB in order to provide the BLER performances corresponding to the requested Quality of Service. The initial UL SIRtarget value is a function of the QoS requirements for the different radio bearers multiplexed on the uplink. After that, Outer loop power control will update SIRtarget based on need. This control loop runs in the RNC with a speed up to 100 Hz and may use various parameters to adjust the SIRtarget, such as: __ The quality estimate of the data received at the NodeB, this is done by CRC check. __ The number of soft legs, __ The interference/load level in the uplink channel, __ Measurement reports from the UE. The new SIRtarget is then sent to the NodeB over the IuB/Iur links and is used by the inner loop function located in the NodeB as a reference against the SIRest. This new target value can not be out of range defined by minSIRTarget and maxSIRTarget parameter. Al SIR targets are TFCS (transport Format Combination Set) dependent, i.e. based on service provided. Lucent has not provided detailed description on Outer Loop UL Power control algorithm and suggested that no optimization is needed. Thus this document will not further discuss UL Outer Loop Power Control . Cingular has requested further details and optimization should be directed by HQ and Lucent only.
Network Services
4.3.2.9
DL Power Balancing
When a UE is in soft handover state, the downlink transmission power of the Node Bs connected to that particular UE is balanced, in other words power drifts should not occur. That is because the Transmit Power Control (TPC) commands are common to all of the Node Bs connected to a particular UE. The transmitted TPC commands, however, might be corrupted. This results in an imbalance in the DL transmission power of the UEs radio links, see Fig. below. One of the Node Bs might increase or decrease the transmitted power resulting in an increase in interference or in a loss of diversity gain. In both cases, a loss of traffic capacity in the DL will be incurred.
Figure 66 Power Drifting The objective of DL power balancing is to gradually change the DL transmission power. Thus the drift in the DL transmitted powers of the Node Bs, resulting from the erroneous TPC, is reduced without any interference to the Inner Loop Power Control procedure. Power imbalance does not deteriorate the performance of the imbalanced links; it may improve it slightly. The main issue is that the overpowered transmission pollutes unnecessarily the other radio links in the vicinity, thus leading to a lower radio network capacity. From a RNC perspective, the Imbalance Correction procedure for a given UE shall be activated or deactivated at the S-RNC by setting the Imbalance Correction parameter in the RNC MIB either to Active or Inactive. There shall be one Imbalance Correction parameter per downlink Radio Access Bearer combination, i.e. one for Standalone Signaling, one for Voice + Signaling, etc ... There shall be also one downlink reference Power (dLReferencePower), Adjustment Period(adjustmentPeriod), Adjustment Ratio(scaleAdjustmentRatio) and Max Adjustment Step parameters per downlink Radio Access Bearer combination. These parameters are described in following sections. The activation of the Imbalance Correction for one particular UE shall occur either: At the call set up Upon modification of the number of radio bearer services multiplexed onto the physical channel.
Upon such activation or deactivation, a Power Control Request message will be sent to NodeB via NBAP signaling message. DL power balancing is started simultaneously by SRNC. The power drift between a new link and any existing links is thus avoided.
Network Services
4.3.2.9.1
Power Balancing Algorithm
Once power balancing is active on a radio link, the power balancing adjustment Pbal(k) is superimposed on DPDCH that is used in Inner Loop power control, described in 4.3.2.8.1. The power adjustment The Node B calculates a power balancing term PBAL(k) once every adjustment period k:
P(i) is the code power of the last slot of the previous adjustment period. If the last slot of the previous adjustment period is within a transmission gap due to compressed mode, P(i) is set to the same value as the code power of the slot just before the transmission gap. The adjustment period k is specified by the RNC CLI parameter adjustmentPeriod. Default is 1 frame. . PREF is the value of the DL reference power relative to PP-CPICH. The latter represents the power value used on the primary CPICH. It is defined by RNC CLI parameter dLReferencePower. The adjustment ratio parameter r represents the DL power convergence coefficient. Its value is determined in combination with the adjustment period parameter. If the value of the convergence ratio is close to zero, the impact on the inner loop power control procedure is large. The change due to PBAL, however, is required to be much smaller than the effect of the TPC commands. If the value of the convergence ratio is close to 1, then the adjustment speed is slower. This is defined by parameter scaleAdjustmentRatio, default is 50 meaning 0.5. The adjustments are started at the first slot of a frame when the CFN, modulo the value of the adjustment period IE, is equal to 0. This process is repeated for every adjustment period and restarts at the first slot of a frame with CFN=0. In order to limit the impact on the inner loop power control procedure, the power adjustments are spread over a number of slots determined by the maximum adjustment step that is specified by the maxAdjustmentStep parameter. It defines the number of slots, in which the maximum power adjustment is 1 dB. The default is 2 slots in Lucent.
The power adjustments PBAL(i), resulting from the calculated PBAL(k), are applied during the calculation of the DL transmit power (DPDCH) as follows:
P(i+1) = P(i) + PBAL(i + 1) + TPC(i + 1)

Following figure illustrates such algorithm: In which: Sgn is a function returning a integer indicating the sign of a number. Sgn (X) = 1 Sgn (X) = 0 Sgn (X) = -1 if X > 0 if X = 0 if X < 0
CFN = Connected Frame Number Pinit = P(i) described above

Network Services
Figure 67 Power Balancing 4.3.2.10 DL Common Channel Power Setting Following downlink physical common channels are supported: Common Pilot Channel (CPICH) with sub-channels Primary CPICH (P-CPICH) and Secondary CPICH (S-CPICH). Primary Common Control Physical Channel (P-CCPCH): this channel is used to carry the BCH. Secondary Common Control Physical Channel (S-CCPCH): this channel is used to carry the FACH and PCH. In U03.01 only one S-CCPCH is supported, both PCH and FACH channels are multiplexed over this channel. Synchronization Channel (SCH) with two sub-channels the Primary SCH (P-SCH) and the Secondary SCH (S-SCH). Paging Indicator Channel PICH Acquisition Indicator Channel AICH
All these channels transmit at constant power. (FACH could have loop control but not implemented in 03.01). P-CPICH power is defined in dBm and all others are defined in dB with respect to P-CPICH level. o Common Pilot Channel with sub-channels Primary CPICH (P-CPICH)
Network Services
The rule of thumb for P CPICH is to have 5 10% of total cell power for CPICH. It is the utmost important physical channel as it is used as reference for all other common control channels that together will define the cell size. P-CPICH is also used in stage 3 of cell search. P-CPICH does not have power control. Its power is defined by parameter pCPICHpower, default is +33 dBm. o Primary Common Control Physical Channel (P-CCPCH) that carries the BCH BCH is used to carry critical system information such as RRC system information broadcast that contains parameters used for Idle mode procedure as well as connection mode. BCH does not have power control. Its power is defined as offset to PCPICH power by parameter bchPower Default is -3 dB (meaning 3 dB lower than CPICH power). Note that P-CCPCH has 90% duty cycle as 10% of the time it is used for P-SCH and S-SCH. o Secondary Common Control Physical Channel (S-CCPCH) that carries the FACH and PCH. FACH (forward access channel) and PCH (paging channel) are time-multiplexed on S-CCPCH. They are used to carry RRC signaling message such like RRC Connection setup carried on FACH (as seen on Layer 3 DL CCCH, see figure in 4.3.2.5). When one is active, DTX is applied on the other one. Following tow figures depict the S- CCPCH structure and the power offset in S-CCPCH.
TFCI: Transport Format Combination Indicator K: determines the total number of bits per downlink S-CCPCH slot. Figure 68 S- CCPCH structure and the power offset in S-CCPCH In Lucent, separate parameters are used to set the PO1 and PO2 for FACH and PCH. pCHPower defines the SCCPCH power used for PCH, fACHSigPower defines the SCCPCH power used for Signaling FACH. There is another parameter for Traffic FACH (used for carrying low data rate data session) fACHTraPower. Also there are powerOffset1 and powerOffset2 parameters for both FACH and PCH. Synchronization Channel (SCH) with sub-channels Primary SCH and Secondary SCH.
Network Services
These two channels are needed for stage 1 and stage 2 of cell search. They are only active in 10% of the time so their impact on power assumption is low. Nevertheless, too lower values will result in degraded performance of cell search. Commonly their powers are equivalent to about half of P-CPICH. . o Paging Indicator Channel PICH PICH channel is a fixed rate physical channel (SF=256) used to carry the paging indicator to notify targeted UE to tune to next Paging Channel (PCH) for paging. It is defined by parameter pICHPower relative to value of P-CPICH. Due to its frame structure (288 bits out 300 bits are used), PICH has a power duty cycle of 96%. o Acquisition Indicator Channel AICH AICH is a fixed rate physical channel (SF=256) used to acknowledge reception of RACH from UE in Uplink so UE can start RRC connection. Its power is set to a relative value to P CPICH and defined by parameter aICHPower. Its transmitted only when RACH preamble need to be acknowledged. 55 Downlink Load due to Common Control Channel power assumption The DL Load caused by Common Control channels can be calculated with following formula: DL Load_CCCH = Sum (P_CCCH * Power duty cycle) P_CCCH stands for all common control channel described above and power duty cycle varies by channel type: P-CPICH = 100%; P-SCH = 10%; S-SCH = 10%; BCH = 90%; PICH = up to 96%; PCH = vary FACH = vary; AICH = on need Practically, the total DL load caused by common control channel is around 15- 20%.
Network Services
4.3.2.11 Engineering Guideline for IRAT related parameters 4.3.2.11.1 Summary table
parametername parameternamein database range 24.0,23.9...+1.5 UEGTFCSInstance: (1,2,3,4,5,6,7,9,11, 13,14=19.0dB) (31,32,33,34,35,36= 18.0dB) Cingulardefault description
EcNotarget(prev. slRTarget)
asperUEGTFCS
Usedforthecalculationoftheinitial transmitpowerofthefirstradio link. Thismarginisusedinorderto allowchangesinthelinkbudget betweenthetimetheCPICH measurementsareperformedatthe UEandthetimethefirstradiolink isactive. Usedforthecalculationoftheinitial transmitpoweroftheradiolinks otherthanthefirstone.
DownlinkOpenLoop PowerControl
dLPowerMargin
10,9.9,+10
newLegPowerOffse t
0,0.1,.25.5 UEGTFCSInstance: (1,2,4,5,6,7,9,11= +5dB) (3,13,14,31,32,33, 34,35,36=+6dB) 6.3,6.20 DedTrChannel instance: (1=2(1%)) (2,3,4=2.1(0.7%)) (5=3(0.1%)) (6,7,9,20,21,22= 1.3(5%))
asperUEGTFCS
DownlinkOuterLoop PowerControl
bLERQualityTarget
asperUEGTFCS
ItprovidestheDownlink BLERtarget.
limitedDLPowerIn crease
True/False
TRUE(allothers) False(DTCH= 2,3,4,5) 10 15
IndicateswhetherDLpower increaselimitationisallowedforthe DPDCHwhereitismapped ParameterfortheDLPower IncreaseLimitationalgorithm. ParameterfortheDLPower IncreaseLimitationalgorithm. Itdefinestheadjustmentstep specifiedinthedownlinkpower controlcommands. ItdefinestheDownlinkPower ControlmodessupportedbytheUE. Minimumdownlinkpowerlevelfor agivencodepower.
PowerRaiseLimit DownlinkInnerLoop PowerControl DLPowerAvWindo wSize
[0,10] [1,60] {TPC05=0.5, TPC10=1, TPC15=1.5, TPC20=2} sINGLETPC 35,34.9+15 35,34.9+15 UEGTFCSinstance: (1,4,13,31,50,54= +3dB)(2=0dB)(9,32 =4dB) (Others=+6dB)
tPCStepSize
TPC10
Downlinkpower controlmodeparameter
dPCMode minDLPower
sINGLETPC 19
maxDLPower
follows UEGTFCS
Maximumdownlinkpowerlevelfor agivencodepower.
Network Services

Localcorrectiontothevalueof minDLPowerusedtodefinetheDL dynamicrangeofdedicatedradio linksonacellbasis. Localcorrectiontothevalueof maxDLPowerusedtodefinetheDL dynamicrangeofdedicatedradio linksonacellbasis. Definesifimbalancecorrectionof downlinktransmitpowershouldbe activatedornot. Definesatimeperiod,intermsof numberofslots,inwhichthe accumulatedpoweradjustment shallbemaximum1dB.Thisvalue doesnotincludetheDLinnerloop PCadjustment. Maximumtimeallowedforthe applicationofthebalancecorrection whichvaluehasbeencalculatedat thebeginningofthecorrection period. Definestheconvergencerateused fortheassociatedAdjustment Period.
PminCorrectionFac tor
10.0,9.9+10
PmaxCorrectionFac tor ImbalanceCorrectio n
10.0,9.9+10
TRUE
maxAdjustmentSte p
[1,10]slots
adjustmentPeriod PowerImbalance scaleAdjustmentRa tio
[1,2,256]frames
[0100]
50
dLReferencePower
[35,34.9+15] UEGTFCSinstance: (1=10dB) (2=20dB) (3,4,6,10,31=14dB) (5,7,33,36=8dB) (8=17dB) (9,32,34,35=11dB) (11=10dB)
follows UEGTFCS
ReferencePowerlevelforimbalance correctionalgorithm
DownlinkDCHpower offsetsparameters.
pO1
(0.0,0.25,6.0)
PoweroffsetfortheTFCIbits. ValuesgreaterthanzeroforTFCI poweroffsetmayimprovetheBLER performances. PoweroffsetfortheTPCbitswhen thereisonlyoneradiolinkset connectedtotheUE.Valuesgreater thanzeroforthisoffsetmayreduce theTPCcommanderrordetection rate. PoweroffsetfortheTPCbitswhen therearetworadiolinksset connectedtotheUE.Valuesgreater thanzeroforthisoffsetmayreduce theTPCcommanderrordetection rate. PoweroffsetfortheTPCbitswhen therearethreeradiolinksset connectedtotheUE.Valuesgreater thanzeroforthisoffsetmayreduce theTPCcommanderrordetection rate.
pO2ForOneRLSet
(0.0,0.25,6.0)
pO2ForTwoRLSet
(0.0,0.25,6.0)
pO2ForThreeRLSet AndMore
(0.0,0.25,6.0)
Network Services

Poweroffsetforthepilotbits. Currentdefaultvalueforpilot poweroffsetimprovestheUE synchronizationandincreasesthe downlinkcapacitygain. Activate/deactivatedtheinnerloop powercontrolfeature. duringtheframecontainingthe startofthefirsttransmissiongapin thetransmissiongappattern (withoutincludingtheeffectofthe bitrateincrease).ThisDeltawillbe appliedtotheuplink/downlink transmissionpowercontrol procedure. DeltaSIRtargetvaluetobesetinthe NodeBoneframeaftertheframe containingthestartofthefirst transmissiongapinthetransmission gappattern. DeltaSIRtargetvaluetobesetinthe NodeBduringtheframecontaining thestartofthesecondtransmission gapinthetransmissiongappattern (withoutincludingtheeffectofthe bitrateincrease).Whenomitted, DeltaSIR2=DeltaSIR1. DeltaSIRtargetvaluetobesetinthe NodeBoneframeaftertheframe containingthestartofthesecond transmissiongapinthetransmission gappattern.Whenomitted, DeltaSIRAfter2=DeltaSIRAfter1 PrimaryCPICHpower,indBmThe settingstronglydependsonthecell planning.Thissettinginfluencethe poweroftheotherDLcommon channels,theDLDCHpowerlimits valuesandtheIAOCscalingfactors. CPICHpowerhasalsostrong impactonsynchronizationaswellas onsoft/softerhandoverprocedures. PrimarySCHpower,indBwith respecttoPCPICHpowerCurrent settingensureshighsuccessratein differentstepsofcell search/synchronizationprocedureas wellaslowDLpowerconsumption (dutycycle10%). SecondarySCHpower,indBwith respecttoPCPICHpower.Current settingensureshighsuccessratein differentstepsofcell search/synchronizationprocedureas wellaslowDLpowerconsumption (dutycycle10%).
pO3
(0.0,0.25,6.0)
Deactivationofthe downlinkinnerloop powercontrol
innerLoopPCStatus
TRUE
deltaSIR1
0,0.01,3
deltaSIRAfter1 Downlinkpower controlincompressed mode deltaSIR2
0,0.01,3
0,0.01,3
deltaSIRAfter2
0,0.01,3
POWERSETTINGS FORDOWNLINK COMMON CHANNELS
pCPICHpower
10,9.9,+50
36
pSCHpower
35.0,34.9,+15.0
sSCHpower
35.0,34.9,+15.0
Network Services

BCHpower,indBwithrespectto PCPICHpowerCurrentsetting ensureshighsuccessratein decodingSIBandMIBmessagesas wellaslowDLpowerconsumption (dutycycle90%). PoweroffsetoftheSecondary CCPCHTFCIfieldrelativetothe transmissionpowerofthedatapart (PCHorFACH).Valuesgreaterthan zeroforTFCIpoweroffsetmay improvetheBLERperformances PoweroffsetoftheSecondary CCPCHpilotfieldrelativetothe transmissionpowerofthedatapart (PCHorFACH).Valuesgreaterthan zeroforpilotpoweroffsetmayhelp theUEtoachievesynchronization andperform abetterreceptionoftheSCCPCH. PCHpower,indBwithrespecttoP CPICHpower PICHpower,indBwithrespectto PCPICHpower FACHpower,indBwithrespectto PCPICHpower. FACHpower,indBwithrespectto PCPICHpower SameasfortheSCCPCHPch SameasfortheSCCPCHPch Definestheoutputpowerlevelof theAICHphysicalchannel,indB withrespecttoPCPICHpower. Currentsettingensuresuccessful decodingattheUEofAImessages alongRACHAccessprocedures. Usedtodetermineinitialtransmit powerofanewDTCH.Value expressedindB. Indicateslengthofpowercontrol preamble.Expressedinnumberof radioframes.NoPCpreambleis currentlyusedtodelayuplink DPDCHtransmissionafteruplink DPCCHtransmission.Thereasonis thatsomeUEscrashifthevalueis otherthan0. Itdefinesthemetrictobeselected forradiolinkqualityestimation. Thissettingsmeansthattheselected metricforradiolinkquality estimationisthePhysicalChannel BER.
bCHPower
35.0,34.9,+15.0
secondaryCCPCH. powerOffset1
0.0,0.25,6.0
secondaryCCPCH. powerOffset2
0.0,0.25,6.0
pCHPower pICHPower fACHTrafPower fACHSigPower secondaryCCPCH. powerOffset1 secondaryCCPCH. powerOffset2
35.0,34.9,+15.0 10,9.9,+5 35.0,34.9,+15.0 35.0,34.9,+15.0 0.0,0.25,6.0 0.0,0.25,6.0
4 7 2 4 0 0
aICHPower
22,21.9,+5
UplinkOpenLoop PowerControl
dPCCHPowerOffse t
164,1626
84
pCPreamble
0..7
qESelector
Y=selected, N=nonselected DedTransport Channelinstance: (Allexcept3and4= Y) (3and4=N)
followsDed Transport channelselected
Network Services

0.000,0.0010.512 DedTransport channelinstance:(1= 0.002) (2,5=0.001) (3,4=0) (6,7,9,20,21,22= 0.01) 0.000,0.0010.512 DedTransport channelinstance:(1, 5,6,7,9,20,21,22= 0.2) (2=0.15) (3,4=0) 0.0,1,0.255.0 DedTransport Channelinstance:(1, 3,4=255.0) (2,5,6,7,9=130.0) (20,21,22=150.0) 0,0.1.10 0.000,0.0010.512 DedTransport channelinstance:(1= 0.4) (2=0.025) (3,4=0) (5,6,7,9,20,21,22= 0.05) [0,1.255] DedTransport channelinstance:(1, 6,7,9=120) (2,3,4=250) (5=200) (20,21,22=160)
downSIRStep
followsDed Transport channelselected ItdefinestheuplinkSIRtarget decrementstepindB.Current valuesensurequickOLPCreaction inhighlyvariableRFenvironment withoutcausingspikesinSIRtarget. followsDed Transport channelselected
upSIRStep
qEThreshold
ItdefinestheQEthresholdfor allowingdecrementofSIRtargetin dB.Thisvaluedisablesthecheckin OLPContheQualityEstimation, thusOLPCdecisiononSIRtarget calculationarebasedonlyonCRC checkresults. Itdefinesthehysteresisfactorused torestrictSIRtargetupdateindB.
sIRAllowance
sIRDownAdditiona l
ExtraUPLINKSIRtargetdecrement whenaTransportblockisreceived withCRCI=ok.UsedwhenHigh SpeedSIRTargetDecreaseisactive.
NbOfConsecutiveG oodFramesThresho ld
ThresholdforactivationofHigh SpeedSIRTargetDecrease
SIRtargetrelated parameters
initialSIRTarget
8.2,8.1,+17.3 UEGTFCSinstance: (AllExcept2,3,13,14 =+7dB) (2=+5dB) (3,13,14=+6dB)
follows UEGTFCS
InitialSIRtargetfortheconsidered radiobearerexpressedindB.Setting dependsonpowerimbalanceand DLOLPCissues.Shouldbefurther optimizedinordertominimizethe convergencetime,hencetheuplink power consumption&noiseriseduringthe transientperiod.
minSIRTarget
8.2,8.1,+17.3 UEGTFCSinstance: (AllExcept3=0dB) (3=+4.9dB)
follows UEGTFCS
MinimumSIRtargetforconsidered radiobearerindB.
Network Services

8.2,8.1,+17.3 UEGTFCSinstance: (AllExcept2,13,14, 31,32,33,34,35,36= +8dB) (2,13,14=+7dB) (31,32,33,34,35,36= +9dB)
maxSIRTarget
follows UEGTFCS
MaximumSIRtargetforconsidered radiobearerindB.
tPCStepSizeUL Uplinkpowercontrol stepsizeandUE transmitpowerlimit parameters.
0(1.0dB),1(2.0dB)
Adjustmentstepspecifiedinthe uplinkpowercontrolcommands0 means1dB,1means2dBsteps. Thisisthehighestpermittedvalue ensuringmaximumuplink coverage.Itmaybedecreasedin caseofuplinkinterferenceissues. Itspecifiesthealgorithmtobeused byUEtointerpretTPCcommands ItdefinestheDPCCHgaingivenfor thehighestrateoftheTransport FormatCombinationStructure (TFCS).Currentvalueshelpto mitigatethepowerimbalanceeffects byincreasingbothDPCCHand DPDCHperformanceswithout causinghighuplinkpower consumption. ItdefinestheDPDCHgaingivenfor thehighestrateoftheTFCS.Current valueshelptomitigatethepower imbalanceeffectsbyincreasingboth DPCCHandDPDCHperformances withoutcausinghighuplinkpower consumption ItdefinestheDPCCHgaingivenfor thehighestrateoftheTransport FormatCombinationStructure (TFCS).Currentvalueshelpto mitigatethepowerimbalanceeffects byincreasingbothDPCCHand DPDCHperformanceswithout causinghighuplinkpower consumption. ItdefinestheDPDCHgaingivenfor thehighestrateoftheTFCS.Current valueshelptomitigatethepower imbalanceeffectsbyincreasingboth DPCCHandDPDCHperformances withoutcausinghighuplinkpower consumption Itdefinesthemethodtoeither directlysignallingorcomputingthe gainfactors. Itdefinesthereferencenumberin casecomputedmethodisused.
maxULDPCHPowe r
50,..,+33
33
PowerControlAlgo rithm
(pCALGORITHM1, pCALGORITHM2)
pCALGORITHM 1
TFC0.gainFactorBc
015
12
TFC0.gainFactorBd
015
15
Uplinkinnerloop powercontrol DPCCH/DPDCHpower gainsparameters.
TFC1.gainFactorBc
015
12
TFC1.gainFactorBd
015
15
gainFactorType
(sIGNALLED, cOMPUTED)
sIGNALLED
referenceTFC
Network Services

DeltaSIRtargetvaluetobesetinthe UEduringtheframecontainingthe startofthefirsttransmissiongapin thetransmissiongappattern (withoutincludingtheeffectofthe bitrateincrease).ThisDeltawillbe appliedtothe uplink/downlinktransmission powercontrolprocedure. DeltaSIRtargetvaluetobesetinthe UEoneframeaftertheframe containingthestartofthefirst transmissiongapinthetransmission gappattern. DeltaSIRtargetvaluetobesetinthe UEduringtheframecontainingthe startofthesecondtransmissiongap inthetransmissiongappattern (withoutincludingtheeffectofthe bitrateincrease).Whenomitted, DeltaSIR2=DeltaSIR1. DeltaSIRtargetvaluetobesetinthe UEoneframeaftertheframe containingthestartofthesecond transmissiongapinthetransmission gappattern.Whenomitted, DeltaSIRAfter2=DeltaSIRAfter1 Maximumdownlinkpower,indBm allowedinthecell.
deltaSIR1
0,0.01,3
deltaSIRAfter1 CompressedMode Parameters
0,0.01,3
deltaSIR2
0,0.01,3
deltaSIRAfter2
0,0.01,3
Poweroverloadcontrol parameter.
maxTransmissionP ower
30.0,30.1.46.0
46
4.3.2.11.2 Engineering Guideline This section contains parameters that most relevant to performance and could be subject to changes based on trails, or the parameters that are key to understanding of certain basis functions. There are other parameters in Lucent system but either with low sensitivity or will not be subject to field trials for relatively long time, these parameters are not discussed here. If interested, one can find more information on these parameters in Lucent Power Control TAN. Following parameters are organized in alphabet order for easy reference and described in following fashion: Name of parameters Parameter Name in database: as seen on OMC GUI Access in OMC GUI :navigation path to locate the parameter and how this parameter is accessed (if or not the object has to be blocked) Unit & Range Granularity: network element levels this parameter can be accessed (RNC, Cell level, etc.) Description: Dependencies and constraints: is this parameter correlated to other parameters and any constraints on how this parameter value should be set. Setting Tradeoff: impact when the value is set to high and low values. Engineering Recommendation: Cingulars choice on parameter value based on latest strategy and/or field study. AccessRules
Network Services
RW RO ROSC RWLO RWPL RWEL RWDC Access Interface RNCCLI OMC
The parameter is read-write The parameter is read-only The parameter is writable at creation then it is read-only The parameter is read-write only when the object is locked The parameter is read-write only when parent object is locked The parameter is read-write only when top-level object is locked DC = Direct Connect (parameters are adjustable via LMT, only). LMT = Local Maintenance Terminal
UEGTFCSInstanceandassociatedservicecombination
Network Services
DedicatedTransportChannelInstancesandassociatedradiobearer
Network Services
DLOpenLoopPowerControlParameters
EcNoTarget
Parameter Name in database: EcNoTarget Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: -24.0 ... + 1.5 dB in step of 0.1. defined per TFCS instance. Granularity: per RNC Description: Used for the calculation of the initial transmit power of the first radio link. See 4.3.2.7.1 for details. Dependencies and constraints: n/a Setting Tradeoff: higher is the value, higher will be the power of initial DPDCH. This will increase power level in DL thus raise overall DL interference. Too low value will result in insufficient power in DL before DL inner loop power takes effect. This could lead to failed call setup. Engineering Recommendation: (1, 2, 3, 4, 5, 6, 7, 9, 11, 13, 14 = -19.0dB) (31, 32, 33, 34, 35, 36, 50, 51, 52, 54 = -18.0dB), 19, 23, 26, 28 are meant for HSDPA and 47, 48 have 384 k in UL which is not available in 03.01 load
DLPowerMargin
Parameter Name in database: dlPowerMargin Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: -10, -9.9, +10 dB in step of 0.1. Defined per TFCS instance. Granularity: per RNC Description: This margin is used in order to allow changes in the linkbudget between the time the CPICH measurements are performed at the UE and the time the first radio link is active. See 4.3.2.7.1 for more details. Dependencies and constraints: n/a Setting Tradeoff: it has similar effect of EcNo Target. Engineering Recommendation: 3 dB for all TFCS instance.
NewLegPowerOffset
Parameter Name in database: newLegPowerOffset Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: 0, 0.1, .25.5 dB in step of 0.1. defined per TFCS instance. Granularity: per RNC Description: Used for the calculation of the initial transmit power of the radio links other than the first one, in case of soft HO, see 4.3.2.7.2 for more details. Dependencies and constraints: n/a Setting Tradeoff: it has similar effect of EcNo Target. Its impact will be magnified with more call involved in SHO mode. Engineering Recommendation: ( 1, 2, 4, 5, 6, 7, 9, 11 = +5dB) (all others = +6dB).
ULOpenLoopPowerControlParameters
DLDPCCHPowerOffset
Parameter Name in database: dPCCHPowerOffset Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: -164, -162-6dB in step of 2. defined per TFCS instance. Granularity: per RNC Description: Used to determine initial transmit power of a new DTCH. See 4.3.2.6.2 for more details.
Network Services
Dependencies and constraints: n/a Setting Tradeoff: If parameter is too small, the initial DPCH transmission is received by the Node B at lower level than required for acquisition, and the acquisition time increases. If parameter is too large, the initial DPCH transmission is received by the Node B at higher level than required for acquisition and the uplink interference unnecessarily increases. This parameter is influenced by UL interference level and CPICH power. Higher is either one of them, higher should this power offset be. Engineering Recommendation: -84 dB until further trial .
PowerPreamble
Parameter Name in database: pCPreamble Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: 0..7 Frames in step of 1. defined per TFCS instance. Granularity: per RNC Description: Indicates length of power control preamble. Expressed in number of radio frames. Dependencies and constraints: n/a Setting Tradeoff:. If the parameter is set too low, the DPDCH transmission is started before tinner loop power control has converged to the setpoint, which may create excess uplink interference or insufficient UL power for the DPDCH resulting in dropped TTIs initially. If the parameter is set too high, outer loop start time and two-way voice connectivity are delayed. Two-way voice will be delayed minimally (up to 80ms). Engineering Recommendation: 7 DLInnerLoopPowerControlParameters
DLPowerAverageWindowSize
Parameter Name in database: DLPowerAveWindowSize Access in OMC GUI: Lcell on OMC GUI or RNC CLI, In LCell info object table. RO-SC Unit & Range: 160 step of 1. Granularity: per cell Description: to determine the time during which regular inner loop power control algorithm takes effect. After which the limited power increase function will be used to limit the increased speed of inner power control loop for NRT transfer. RLC retransmission is used to compensate the resulting errors. This algorithm is believed to increase DL capacity. See 4.3.2.8.1 for more details. Dependencies and constraints: n/a Setting Tradeoff: longer is the value, later will the limited power increase function take effect. Therefore, minor DL interference increase could occur. Engineering Recommendation: 15 frame until further trial
DLPowerControlMode
Parameter Name in database: dPCMode Access in OMC GUI: RNC CLI Only, RW-EL Unit & Range: single TPC Mode only. Granularity: per RNC Description: It defines the Downlink Power Control modes supported by the UE. See 4.3.2.8.1 for more details. Dependencies and constraints: n/a Setting Tradeoff:. Engineering Recommendation: Lucent only support SingleTPC Mode
LimitedDLPowerIncrease
Parameter Name in database: limitedDLPowerIncrease Access in OMC GUI: RNC CLI, per UEGTFCS, RW-EL
Network Services
Unit & Range: Y or N. Granularity: per RNC Description: if or not limited power increase is enabled. See 4.3.2.8.1 for more details. Dependencies and constraints: n/a Setting Tradeoff: Engineering Recommendation: Yes (enabled) on all TFCS but 2, 3, 4, 5
MaximumDLPower
Parameter Name in database: maxDLPower Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: -35, -34.9. +15 dB in step of 0.1. defined per TFCS instance. Granularity: per RNC Description: Maximum downlink power level for a given code power. Dependencies and constraints: n/a Setting Tradeoff: higher value will result in loss of capacity. If the maximum power for each DCH is set too high, the capacity of the cell might be severely limited in case multiple UEs are at the cell edge. If the maximum power is set too low, the coverage for that service might be severely limited compared to the CPICH coverage area or compared to other services. Lucent studies have shown that in current network the maximum power is used less 0.3% of time so the impact (interference) is minimal. However, the capacity and performance tradeoff will warrant revision of the setting eventually. Engineering Recommendation: UEGTFCS instance : (1, 4, 13, 31, 50, 54 = +3dB) (2 = 0 dB) (9, 32 = 4 dB) (Others = +6dB)
MinimumDLPower
Parameter Name in database: minDLPower Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: -35, -34.9. +15 dB in step of 0.1. defined per TFCS instance. Granularity: per RNC Description: Minimum downlink power level for a given code power. Dependencies and constraints: n/a Setting Tradeoff: Engineering Recommendation: -19 dB (CPICH 19 dB) for all UEGTFCS (all RABs)
PowerRaiseLimte
Parameter Name in database: powerRaiseLimit Access in OMC GUI: OMC LCell or RNC CLI, In DLDPCH info object table. RO-SC Unit & Range: 0,..10 in step 1 . Granularity: per RNC Description: used in Limited Power Increase algorithm. See 4.3.2.8.1 for more details. Dependencies and constraints: Setting Tradeoff: . Engineering Recommendation: -10 until further trial
PowerOffset1
Parameter Name in database: pO1 Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: 0, 0.25, . 6 dB in step of 0.25. defined per TFCS instance. Granularity: per RNC
Network Services
Description: Power offset for the TFCI bits of DPCH Dependencies and constraints: n/a Setting Tradeoff: Values greater than zero for TFCI power offset may improve the BLER performances. Engineering Recommendation: 0 dB for all UEGTFCS (all RABs)
PowerOffset2forOneRLSet
Parameter Name in database: pO2ForOneRLSet Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: 0, 0.25, . 6 dB in step of 0.25. defined per TFCS instance Granularity: per RNC Description: Power offset for the TPC bits when there is only one radio link set connected to the UE. Dependencies and constraints: n/a Setting Tradeoff: Values greater than zero for this offset may reduce the TPC command error detection rate. Engineering Recommendation: 0 dB for all UEGTFCS (all RABs)
PowerOffset2forTwoRLSet
Parameter Name in database: pO2ForTwoRLSet Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: 0, 0.25, . 6 dB in step of 0.25. defined per TFCS instance Granularity: per RNC Description: Power offset for the TPC bits when there are two radio links set connected to the UE. Dependencies and constraints: n/a Setting Tradeoff: Values greater than zero for this offset may reduce the TPC command error detection rate. Engineering Recommendation: 3 dB for all UEGTFCS (all RABs)
PowerOffset2forThreeRLSetsormore
Parameter Name in database: pO2ForThreeRLSetAndMore Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: 0, 0.25, . 6 dB in step of 0.25. defined per TFCS instance Granularity: per RNC Description: Power offset for the TPC bits when there are three or mroe radio links set connected to the UE. Dependencies and constraints: n/a Setting Tradeoff: Values greater than zero for this offset may reduce the TPC command error detection rate. Engineering Recommendation: 6 dB for all UEGTFCS (all RABs)
PowerOffset3
Parameter Name in database: pO3 Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: 0, 0.25, . 6 dB in step of 0.25. defined per TFCS instance Granularity: per RNC Description: Power offset for the pilot bits. Current recommended value for pilot power offset improves the UE synchronization and increases the downlink capacity gain. Dependencies and constraints: n/a Setting Tradeoff: Engineering Recommendation: 2 dB for all UEGTFCS (all RABs)
TPCStepSize
Network Services
Parameter Name in database: tPCStepSize Access in OMC GUI: RNC CLI Only, In DLDPCH info object table. RW-EL Unit & Range: {TPC0-5 = 0.5, TPC1-0 = 1, TPC1-5 = 1.5, TPC2-0 = 2} defined per TFCS instance. Granularity: per RNC Description: It defines the adjustment step specified in the downlink power control commands. Dependencies and constraints: Setting Tradeoff: large value will result in large variance of power control dynamic therefore could result in power over shoot. Engineering Recommendation: TPC1-0 (1 dB) for all UEGTFCS (all RABs)
DLOuterLoopPowerControlParameters BLERQualityTarget
Parameter Name in database: bLERQualityTarget Access in OMC GUI: RNC CLI Only, In dedicated transport channel info object table. RW-EL Unit & Range: -6.3 ... 0 dB in step of 0.1, per dedicated transport channel instance Granularity: per RNC Description: Downlink BLER target for inner loop power control. Dependencies and constraints: Required QoS. Setting Tradeoff: If parameter is too low, downlink DPCH power may be higher than required by the underlying QoS, thus capacity is consumed without noticeable improvement in voice quality. If parameter is too high, there might be an impact on QoS. Note: The BLER is measured on class A bits only (TFCS instance 2). Class B and C bits have no CRC (TFCS instance 3 and 4). . Engineering Recommendation: (Dedicated Transport Channel Instance 1 = -2 (1%)) 3.4 kbps signaling (Dedicated Transport Channel Instance 2, 3, 4 = -2.1 (0.7%)) AMR voice call (Dedicated Transport Channel Instance 5 = -3 (0.1%)) 64 kbps CS data call (Dedicated Transport Channel Instance all others = -1.3 (5%)) all R99 PS call
ULInnerLoopPowerControlParameters MaximumULDPCHPower
Parameter Name in database: maxULDPCHPower Access in OMC GUI: RNC CLI Only, In ULDPCH info object table. RW-EL Unit & Range: -50, ..,+33 dBmin step of 1, per UEGTFCS instance Granularity: per RNC Description: This is the highest permitted value ensuring maximum uplink coverage. It may be decreased in case of uplink interference issues. Dependencies and constraints:. Setting Tradeoff: A higher value allows for an increased link budget on the uplink. A lower maximum transmit power conserves battery power at the price of limited service availability when the UE is at the cell edge. Engineering Recommendation: 33 dBm
PowerControlAlgorithm
Parameter Name in database: PowerContorlAlgorithm Access in OMC GUI: RNC CLI Only, in ULDPCH info object table. RW-EL Unit & Range: algorithm 1, algorithm 2 Granularity: per RNC Description: algorithm 1 allows 1500 Hz inner loop power frequency; algorithm 2 runs inner loop power at frequency of 500 Hz. Algorithm 1 is used when the UE speed is sufficiently low to
Network Services
compensate for the fading of the channel. The PC step size is set by RNP to 1 or 2 dB. Algorithm 2 was designed for emulating the effect of using a PC step size smaller than 1 dB and can be used to compensate for the slow fading trend of the propagation channel rather than rapid fluctuations. It performs better than Algorithm 1 when the UE moves faster than 80 km/h or slower than 3 km/h. In Algorithm 2 the PC step size is fixed at 1 dB. The UE does not change its transmission power until it has received five consecutive TPC commands. For more details on algorithm 2, see 25.214. Dependencies and constraints:. Setting Tradeoff: Engineering Recommendation: algorithm 1
TPCStepSizeUL
Parameter Name in database: tPCStepSizeUL Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: 0 (1.0 dB), 1 (2.0 dB) per UEGTFCS instance Granularity: per RNC Description: Adjustment step specified in the uplink power control commands Dependencies and constraints: must be present if algorithm 1 is specified. Setting Tradeoff: If parameter is too large (2 dB), the power control inner loop variance increases thereby degrading capacity. A step size equal to 1 dB allows for 1.5 dB/msec power control correction (equivalent to 30 dB in 20 ms). A larger inner loop bandwidth is not required. If the UE has low mobility, a 2dB power control step size is actually detrimental to uplink capacity. Engineering Recommendation: 0 (1 dB) for all UEGTFCS but 50 & 54 which use 1 (2 dB). 50 and 54 are services containing HSDPA DL/384kbps UL RAB.
ULOuterLoopPowerControlParameters InitialSIRTarget
Parameter Name in database: nitialSIRTarget Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: -8.2, -8.1,+17.3 in step of 0.1 dB, per UEGTFCS instance Granularity: per RNC Description: Initial SIRtarget for the considered radio bearer expressed in dB. Setting depends on power imbalance and DL OLPC issues. Dependencies and constraints: must be present if algorithm 1 is specified. Setting Tradeoff: Should be further optimized in order to minimize the convergence time, hence the uplink power consumption & noise rise during the transient period. Engineering Recommendation: All Except 2, 3, 13, 14, 47, 48, 49, 50, 51, 52, 53, 54 =+7dB 2 = +5dB 3, 13, 14 = +6dB 47, 48,49, 50, 51, 52, 53, 54 = +8 dB
MaximumSIRTarget
Parameter Name in database: maxSIRTarget Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: -8.2, -8.1,+17.3 in step of 0.1 dB, per UEGTFCS instance Granularity: per RNC Description: Maximum SIR target for considered radio bearer in dB. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: (All UEGTFCS Except 2, 13, 14, 31, 32, 33, 34, 35, 36 = +8dB) (2, 13, 14 = +7dB) (31, 32, 33, 34, 35, 36 = +9dB)
Network Services
MinimumSIRTarget
Parameter Name in database: minSIRTarget Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: -8.2, -8.1,+17.3 in step of 0.1 dB, per UEGTFCS instance Granularity: per RNC Description: Minimum SIR target for considered radio bearer in dB. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: (All UEGTFCS Except 3 = 0dB) (UEGTFCS 3 = +4.9dB) 3 is for 64kbps CS data call
DLPowerBalancingParameters
AdjustmentPeriod
Parameter Name in database: adjustmentPeriod Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: 1256 frames in step of 1, per UEGTFCS instance Granularity: per RNC Description: Maximum time allowed for the application of the balance correction which value has been calculated at the beginning of the correction period. See 4.3.2.10 for more details. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 1 (imbalance correction is effectively on for every frame)
DLreferencepower
Parameter Name in database: dLReferencePower Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: -35, -34.9,+15 dB in step of 0.1 dB, per UEGTFCS instance Granularity: per RNC Description: Reference Power level for imbalance correction algorithm. It is reference in dB to CPICH power. See 4.3.2.10 for more details. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: UEGTFCS instance: (1 = 10dB) (2, 13, 50, 54= -10dB) (3, 4, 6, 10, 31, 47, 51 = -14dB) (5, 7, 33, 36, 49, 52 = -8dB) (8,14 = -17dB) (9, 32, 34, 35, 48, 52 = -11dB) (11 = -10dB)
ImbalanceCorrection
Parameter Name in database: imbalanceCorrection Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: bolean (Y, N) per UEGTFCS instance Granularity: per RNC
Network Services
Description: Defines if imbalance correction of downlink transmit power should be activated or not. See 4.3.2.10 for more details. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: Yes to all UEGTFCS
MaximumAdjustmentStep
Parameter Name in database: maxAdjustmentStep Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: 1, ..10 slot in step of 1, per UEGTFCS instance Granularity: per RNC Description: Defines a time period, in terms of number of slots, in which the accumulated power adjustment shall be maximum 1dB. This value does not include the DL inner loop PC adjustment. See 4.3.2.10 for more details. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2 slots
ScaleAdjustmentRatio
Parameter Name in database: scaleAdjustmentRatio Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: 0. 100, per UEGTFCS instance. The real value used in the algorithm is parameter value /100. example: 50 mean 0.5. Granularity: per RNC Description: Defines the convergence rate used for the associated Adjustment Period. See 4.3.2.10 for more details. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 50 for all UEGTFCS. DLCommonChannelPowerSettingParameters
AICHPower
Parameter Name in database: aICHPower Access in OMC GUI: Lcell PRACH object; RW-PL Unit & Range: -22, -21.9, +5 dB in step of 0.1, as relative to PCPICH power. For instance, -3 means its power level is 3 dB lower than PCPICH power. Granularity: per cell Description: Defines the output power level of the AICH physical channel, in dB with respect to PCPICH power. Dependencies and constraints: If parameter is too small, the probability of acquisition indicator misdetection and false alarm increase. Indicator misdetection leads to increased access time and to increased uplink interference caused by the access attempt. A false alarm causes the UE to send a RACH message packet (e.g., RRC connection setup) which is not expected and not detected by the Node B, thus making the UE wait for a response. Higher layers have to recover from this phenomenon resulting in increased access delay. If parameter is too large, downlink capacity is unnecessarily consumed. Setting Tradeoff: Engineering Recommendation: -6 dB
BCHpower
Parameter Name in database: bCHPower

Network Services
Access in OMC GUI: LCell power tab RW-LO Unit & Range: -35.0, -34.9, +15.0 dB in step of 0.1, as relative to PCPICH power. For instance, -3 means its power level is 3 dB lower than PCPICH power. Granularity: per cell Description: BCH power, in dB with respect to P-CPICH power Current setting ensures high success rate in decoding SIB and MIB messages as well as low DL power consumption (duty cycle 90%). Dependencies and constraints: Setting Tradeoff: if BCH Power is set to high, it wastes DL power resource/capacity; if set too low, it will affects the system information broadcasting leading to reduction in call setup successful rate Engineering Recommendation: - 3 dB.
FACHTrafficPower
Parameter Name in database: fACHTrafPower Access in OMC GUI: Lcell FACH object; RW-PL Unit & Range: -35.0, -34.9, +15.0 dB in step of 0.1, as relative to PCPICH power. For instance, -3 means its power level is 3 dB lower than PCPICH power Granularity: per cell Description: FACH power, in dB with respect to P-CPICH power. For traffic FACH. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: - 2 dB.
FACHSignalingPower
Parameter Name in database: fACHSigPower Access in OMC GUI: Lcell FACH object; RW-PL Unit & Range: -35.0, -34.9, +15.0 dB in step of 0.1, as relative to PCPICH power. For instance, -3 means its power level is 3 dB lower than PCPICH power Granularity: per cell Description: FACH power, in dB with respect to P-CPICH power. For signaling FACH. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 4 dB.
FACHpoweroffset1
Parameter Name in database: fach.secondaryCCPCH.powerOffset1 Access in OMC GUI: Lcell FACH object; RW-PL Unit & Range: 0.0, 0.25, 6.0 dB in step of 0.25 dB. Granularity: per cell Description: Power offset of the Secondary CCPCH TFCI field relative to the transmission power of the data part (FACH). Dependencies and constraints: should be same as Power offset 1 for PCH. Setting Tradeoff: Values greater than zero for TFCI power offset may improve the BLER performances Engineering Recommendation: 0 dB
FACHpoweroffset2
Parameter Name in database: fach.secondaryCCPCH.powerOffset2 Access in OMC GUI: Lcell FACH object; RW-PL Unit & Range: 0.0, 0.25, 6.0 dB in step of 0.25 dB. Granularity: per cell Description: Power offset of the Secondary CCPCH pilot field relative to the transmission power of the data part (PCH or FACH).
Network Services
Dependencies and constraints: should be same as Power offset 2 for PCH. Setting Tradeoff: Values greater than zero for pilot power offset may help the UE to achieve synchronization and perform a better reception of the S-CCPCH. Engineering Recommendation: 0 dB
PCPICHPower
Parameter Name in database: pCPICHpower Access in OMC GUI: LCell power tab RW-LO Unit & Range: -10, -9.9, +50.0 dBm in step of 0.1 Granularity: per cell Description: Primary CPICH power, in dBm The setting strongly depends on the cell planning. This setting influence the power of the other DL common channels, the DL DCH power limits values and the IAOC scaling factors. CPICH power has also strong impact on synchronization as well as on soft/softer handover procedures. Dependencies and constraints: Setting Tradeoff: this parameter is the most important parameter for a cell as it is used as reference for all other common control channel power setting and widely used in many functions like cell search, RACH procedure, open loop power control. Setting it to high value will leave less traffic capacity; setting to low value will reduce the cell coverage Engineering Recommendation: Balance between cell capacity and coverage should be carefully considered when setting this parameter. Simulations and practical experience have suggested 5 10% of total PA power is fairly good practice. At initial launch, this parameter can be set to high end of such range (10% PA power = 36 dBm) to maximize the cell coverage. When traffic grows and capacity needs expansion, P CPICH power can be reduced provided new cells added into system to fill in coverage gap. Current recommendation is 36 dBm.
PCHPower
Parameter Name in database: pCHPower Access in OMC GUI: Lcell PCH object; RW-PL Unit & Range: -35.0, -34.9, +15.0 dB in step of 0.1, as relative to PCPICH power. For instance, -3 means its power level is 3 dB lower than PCPICH power. Granularity: per cell Description: PCH power, in dB with respect to P-CPICH power. Dependencies and constraints: Setting Tradeoff: higher value will consume DL capacity; lower value may affect paging successful rate Engineering Recommendation: 4 dB.
PICHpower
Parameter Name in database: pICHPower Access in OMC GUI: Lcell PCH object; RW-PL Unit & Range: -10.0, -9.9, +5 dB in step of 0.1. relative to CPICH. Granularity: per cell Description: defines the PICH power. Dependencies and constraints: Setting Tradeoff: If set too low, the probability of miss-detection and probability of false alarm increase. If set too high, downlink capacity is wasted Engineering Recommendation: - 7 dB
PCHpoweroffset1
Parameter Name in database pch.secondaryCCPCH.powerOffset1 Access in OMC GUI: Lcell PCH object; RW-PL
Network Services
Unit & Range: 0.0, 0.25, 6.0 dB in step of 0.25 dB. Granularity: per cell Description: Power offset of the Secondary CCPCH pilot field relative to the transmission power of the data part (PCH). Dependencies and constraints: should be same as Power offset 1 for FACH Setting Tradeoff: Engineering Recommendation: 0 dB.
PCHPoweroffset2
Parameter Name in database pch.secondaryCCPCH.powerOffset2 Access in OMC GUI: Lcell PCH object; RW-PL Unit & Range: 0.0, 0.25, 6.0 dB in step of 0.25 dB. Granularity: per cell Description: Power offset of the Secondary CCPCH pilot field relative to the transmission power of the data part (PCH). Dependencies and constraints: should be same as Power offset 1 for FACH Setting Tradeoff: Values greater than zero for pilot power offset may help the UE to achieve synchronization and perform a better reception for the S-CCPCH Engineering Recommendation: 0 dB.
PSCHpower
Parameter Name in database: pSCHpower Access in OMC GUI: Lcell Power tab RW-LO Unit & Range: -35.0, -34.9, +15.0 dB in step of 0.1 Granularity: per Cell Description: Primary SCH power, in dB with respect to P- CPICH power Current setting ensures high success rate in different steps of cell search/synchronization procedure as well as low DL power consumption (duty cycle 10%).. Dependencies and constraints: Setting Tradeoff: P SCH is used in slot synchronization of stage 1 in cell search. Setting it too low will affect the ability of UE at cell border to find the serving cell; setting to high value unnecessarily reduce the DL capacity Engineering Recommendation: - 3 dB
SSCHpower
Parameter Name in database: sSCHpower Access in OMC GUI: Lcell Power tab RW-LO Unit & Range: -35.0, -34.9, +15.0 dB in step of 0.1 Granularity: per Cell Description: Secondary SCH power, in dB with respect to PCPICH power. Current setting ensures high success rate in different steps of cell search/synchronization procedure as well as low DL power consumption (duty cycle 10%). Dependencies and constraints: Setting Tradeoff: S-CH is used in frame synchronization of stage 2 in cell search. Setting it too low will affect the ability of UE at cell border to find the serving cell; setting to high value unnecessarily reduce the DL capacity. Since algorithm used in stage 2 is more robust than stage 1, in theory, SSCH could have less power than P-SCH. Engineering Recommendation: - 5 dB
Network Services
4.3.3
4.3.3.1
Soft/Softer Handovers
Cingular Strategy
SHO is a key function in UMTS system and should be utilized to maximize its benefit while minimizing the burden on Iub interface and RF Interface. Along with the benefit of improved resistance to interference and possible gain on RF quality and capacity through macrodiversity and combining, more resources from RNC, NodeB baseband, Channelisation codes and Iub transmission are involved. Furthermore, certain gain on capacity and reduction of overall transmit power could be undermined by larger power fluctuation at NodeB due to relatively fast switch ON/OFF to accommodate UEs active set update demands, especially when pilot pollution occurs. Also velocity of UE will have impact on SHO performance as resonance problems do occur at some velocities so the UE constantly asks for the wrong NodeB to transmit. Thus it is very important to balance the need for SHO gain and resource efficiency through optimizing SHO related parameters and overall pilot pollution optimization.
4.3.3.2
Overview
The soft/softer handover in 03.01 is a Mobile Evaluated Handover (MEHO) where the UE measures the pilots, performs a filtering of the intra-frequency measurements and reports these measurements to the UTRAN if certain reporting conditions, which are set by the UTRAN, are met. Afterwards, based on the measurement reports sent by the UE, the UTRAN executes the relevant procedures to add/drop/replace radio links. In soft handover, the UE is using simultaneous links with more than one Node B, which may be connected to one or multiple RNC(s). These radio links are combined at the SRNC using the benefit of macrodiversity. Macrodiversity is a concept strongly correlated with soft handover: it is defined as a diversity technique whose purpose is to improve the quality of the mobile communication by minimizing the shadowing effects, i.e. the radio signal attenuation caused by obstacles between UE and Node B. This is achieved by connecting the UE to more that one Node B and (macrodiversity) thresholds determined by the UTRAN. In the uplink the received signal is demodulated and decoded by all the Node B connected to the same UE and then is combined at the RNC. In this scenario the RNC receives a frame (PDU) from each Node B via the Iub, and if necessary the Iur, interfaces. In order to determine which frames can be combined the RNC performs Frame Selection on the multiple received frames and passes on a single to the higher layer. It should be noted that the Frame Selection task is actually selected at a Transport Block (TB) level not at a per frame (PDU) level as the name suggests. The Frame Selection Task involves the use of a Frame Selection Algorithm to determine which TB is of highest quality. Two metrics are used to decide which of the transport blocks received should be passed to the higher level: these are the CRC Indicators (CRCI) and the Quality Estimate (QE) which are both received as part of each PDU. CRC is referred to as a hard indication of quality because it has a pass / fail behavior while QE is referred to as a soft metric since it has a range of values. In the downlink the SRNC performs Frame Distribution, which involves multiple copies of a single frame being distributed to each radio leg. These macrodiversity procedures result in increase of the quality. Therefore soft handover can be defined as a type of handover implemented in a macrodiversity scenario. In softer handover, the radio link exist between UE and different cells (sectors) belonging to the same Node B. The links are combined in the Node B using the benefit of microdiversity. This simply means that in the uplink the received signal from all the cells connected to the same UE is combined in the Node B using the criteria of maximal ratio combining, i.e. using all the received signals together. Softer handover is a type of
Network Services
handover implemented in a microdiversity scenario. Thus in soft/softer handover the radio links use the same frequency and same uplink scrambling code but different downlink scrambling codes. For the correct soft handover functionality, the UE detects and categorizes the pilots in 3 groups: Active Set The signals of the cells in this category are simultaneously demodulated and coherently combined in the UE. User information is sent to the UE and these cells are involved in soft handover. The active set is updated by the UTRAN with the RRC Active Set Update procedure. Monitored Set Cells belonging to this category are not part of the active set bur are regularly measured by the UE and can be included if certain reporting criteria are met. The monitored set is normally a subset of the neighbor list and is updated by the UTRAN with the NLSA (Neighbor List Selection Algorithm) algorithm (see section 5.3 of the Lucent Handover Translation Note) Detected Set The cells included in this category are the unlisted ones, which do not figure in the monitored set provided by the UTRAN via NLSA but are detected by the UE. Intra-frequency measurement and reporting of the detected set is only required from UEs in the Cell_DCH state and can be set via proper UTRAN parameters. A specific parameter is available where measurements and reporting of detected set cells can be switched ON or OFF. Assuming that detected cells can be measured and reported by the UE, they will be added to the active set only if they actually belong to the neighbor list of one of the current active set cells. If they are not registered in any neighbor list of the active set cells, they cannot be added. In this case these cells shall be reported to the OMC for neighbor list optimization purposes via trigger of the relevant PM counter at the RNC. Membership of a pilot set is base on the quality of measurement, like CPICH Ec/No, as seen by the UE which constantly updates the active set in accordance with the RF environment. The procedure used by the RNC to update the active set is named Active Set Update procedure. Basically the Soft/Softer handover procedure for MEHO is composed of four steps illustrated in figure below
Figure 69 MEHO Process It is easy to see that for the proper function of a handover both partners, the UE as well as the RNC, need some network-quality-state information. The static part of this is given by the OMC to the RNC and the dynamic one will won by the UE. Finally the UE and RNC have to exchange their knowledge. There are two handover algorithms: the handover at call setup state and handover in CELL_DCH state. For the call setup phase, the UTRAN broadcasts the relevant parameters for measurements and reporting on SIB11. In cases when a call is going to be established, the UE reports the measurement results on the RACH. The RNC then evaluates the results and sets up the corresponding radio link(s) before the call becomes active. For CELL_DCH, the initial parameter settings for measurements and reports are also broadcast in SIB11. When entering CELL_DCH state, the UE automatically starts to perform measurements and also evaluates the corresponding results. If certain criteria, defined by the UTRAN, are satisfied, then a corresponding event report is sent to the RNC. This event is a trigger for the RNC to ADD and/or REMOVE a radio link for the UE.
Network Services
There is no additional evaluation process in the RNC to decide on handover actions. This decision is already made by the UE by sending the event report. In other words, the actual handover algorithm (decision mechanism) resides in the UE. However, the UTRAN defines the rules by setting the corresponding parameters for the measurement and reporting procedures. When the UE moves through the network then it is possible that the handover parameters need to be changed. Generally, the handover parameters can be set at CELL level due to the individual needs resulting from the different RF conditions. In case the handover parameters need to be changed, a measurement control message with the corresponding settings is sent to the UE. For additional information on soft handover and soft handover algorithms, see Lucents UMTS RF Translation Application Note: Handover U03.01 Version 5.0.
4.3.3.3 4.3.3.3.1
Measurement Control and Reporting Measurement Control
The RNC controls a measurement in the UE via one of the following procedures: Broadcasting of system information block type11 on the BCH if the UE is in Idle mode Transmitting a MEASUREMENT CONTROL message on the downlink DCCH if the UE is in Cell_DCH state
Figure below shows the structure of system Information block type 11:
Figure 70 structure of system Information block type 11 The MEASUREMENT CONTROL message includes all the information needed by the UE, such as the measurement type, the radio links to evaluate, the reporting criteria and a measurement identity number, see figure below for contents in Measurement Control.
Network Services
Figure 71 contents in Measurement Control For Intra-frequency measurement, CPICH Ec/No, CPICH RSCP, path loss, UTRA carrier RSSI can be measured and reported. The most common on is CPICH Ec/No and this is current default recommended by Lucent. This is defined by parameter measQty.quantity. measQty.quantity is a RNC CLI parameter and is not recommended to be changed. This applies to Active Set Reporting, Monitored Set Reporting and Detected Set Reporting. Within the measurement reporting criteria field in the MEASUREMENT CONTROL message, the UTRAN notifies the UE as to which reporting events should trigger a measurement report. UTRAN uses reporting events defined by TS 25.331. The reporting events used for Softer/Soft handover evaluation are: Reporting event 1A: A primary CPICH enters the reporting range. Reporting event 1B: A primary CPICH leaves the reporting range. Reporting event 1C: A non-active primary CPICH becomes better than an active primary CPICH. Reporting event 1D: change of best cell Reporting event 1E: A primary CPICH becomes better than an absolute threshold Reporting event 1F: A primary CPICH becomes worse than an absolute threshold
Lucent only supports 1A, 1B, 1C, 1D in 03.01. The received intra-frequency measurements are sampled by the UE once every measurement period, which is 200 ms in CELL_DCH and CELL_FACH mode. The measurements can be filtered before UE event evaluation using following formula:
Fn =(1-a) Fn-1 + a Mn
Where, Fn is the updated filtered measurement result; Fn-1 is the old filtered measurement result; a is the filter factor;
Network Services
Mn is the latest received measurement result from physical layer;
In order to initialize the averaging filter, F0 is set equal to M1 when the first measurement M1 is received. The filtering ensures that large fluctuations of the UE measurements, which may lead to undesirable behavior along the soft/softer algorithm, are prevented. The relation between k and filter factor a is given by formula below:
a = 1/2(k/2)
similar filtering is applied to many other measurement such like IRAT HO, Inter-frequency HO, Power control, Load Control etc. Lucent 03.01 has default of 3 for this parameter k. It is a RNC CLI only parameter and is not recommended to be changed.
4.3.3.3.2
Reporting
The measurement reporting behavior can be modified by the following parameters: Reporting Range Defines reporting range used by UE for the monitoring of primary CPICH Primary hysteresis for a cell candidate to be either added to (event 1A) or removed (event 1B) from the active set. It is split in two sub-fields per event type. Hysteresis A hysteresis parameter can be connected with each reporting event to limit the amount of eventtriggered reports. Time to trigger The report is triggered only if the conditions for the event have existed for the specified time to trigger. Cell individual offset The cell individual offset is added to the measurement quantity before the UE evaluates if an event has occurred. Event-triggered and periodic intra-frequency measurement reports Verification of events 1A, 1B or 1C can result in an active set update due to radio link addition, deletion or radio link replacement. Both Event triggered and Periodic reporting are specified by 3gPP but only event based is supported in Lucent 03.01. However, if the active set cannot be updated due to no response from UTRAN, the UE can revert to periodical measurement reporting. In this case, the UE transmits measurement report messages to UTRAN at intervals that are predefined by the reporting interval parameter. In Lucent 03.01, this interval is defined by parameter reportingCriteria1X.rcreportingInterval where X denotes A or B or C. Their defaults are set to 1 second. See figure below for example:
Network Services
Note: that SIB 11 also contains measuremetnReprotingMode information and could be set differently but the Measurement Control message will supersede this Information Element. Another parameter will decide when to stop such periodic measurement reportingCriteria1X.rcamtOfRep (X denote A or B or C) which will determine how many times the measurement gets repeated. Current default is infinity meaning no stopping until requested event occur or measurement is stopped by UE due to other reasons listed below: there are no longer any monitored cell(s) within the reporting range. the UTRAN has added cells to the active set so that it includes the maximum number of cells allowed for event 1A to be triggered (Reporting deactivation threshold parameter). the UTRAN has removed cells from the active set so that there is no longer the minimum number of active cells for event 1C to be triggered (Replacement activation threshold parameter).
3GPP also allows measurement reporting for RACH mode so UE can use SHO feature for call setup. However, due to limitation in UE, most infra vendors dont recommend using this feature. In Lucent reporting on RACH can be disabled by setting the parameter measQty.maxNoReportedCellsOnRACH to CURRENTCELL, meaning only current cell is reported. This effectively disable the SHO at call setup.
4.3.3.4
SHO Algorithm
Since the soft/softer handover is MEHO (Mobile Evaluated HO) the RNC, based on these reported measurements, simply takes the required actions to add, remove or replace cells in the active set initiating the soft/softer handover execution through a set of procedures involving the NodeB and the UE. These actions are triggered by recipient of corresponding event report, namely 1A, 1B or 1C.
Event 1A will only be allowed if the total number of cells in active set is less than maximum active set size. Event 1B will only be allowed if the total number of cells in active set is greater than zero. Event 1C will only be allowed if the total number of cells in active set is equal to maximum active set size.
There are two parameters for CS and PS active set size. When a multi-RAB is setup, the larger one of the two will be used for active set size. In Lucent, CS maximum active set size is 4 and PS is 3. Note: in drive test log, one will not see such maximum active set size directly in Measurement control message. Instead, maximum active set size 1 value will be seen in reportDeactivationThreshold for 1A and maximum active set size value seen in replacementReportingThreshold for 1C.
Network Services
Following figure illustrates the triggering of 1A, 1B and 1C events:
Figure 72 triggering of 1A, 1B and 1C events Followings are the triggering condition formula using EcNo as measurement entity (if CPICH RSCP is used, all formula will use <= instead of >=). Triggering Condition for event 1A (radio link addition)
Where, MNew is the measurement result of the cell entering the reporting range. Mi is a measurement result of a cell not forbidden to affect reporting range in the active set. NA is the number of cells not forbidden to affect reporting range in the current active set. MBest is the measurement result of the cell not forbidden to affect reporting range in the active set highest measurement result, not taking into account any cell individual offset. W is a parameter sent from UTRAN to UE. R1a is the Reporting Range constant for event 1A. H1a is the hysteresis value for event 1A. CIOnew is the Cell Individual Offset for the cell entering the reporting range if an individual cell offset is stored for that cell. Otherwise it is equal to 0.
Triggering Condition for event 1B (radio link deletion)
Network Services
Where, MOld is the measurement result of the cell leaving the reporting range. Mi is a measurement result of a cell not forbidden to affect reporting range in the active set. NA is the number of cells not forbidden to affect reporting range in the current active set. MBest is the measurement result of the cell not forbidden to affect reporting range in the active set with the highest measurement result, not taking into account any cell individual offset. W is a parameter sent from UTRAN to UE. R1b is the Reporting Range constant for 1B. H1b is the hysteresis parameter value for 1B. CIOOld is the Cell Individual Offset for the cell leaving the reporting range if an individual cell offset is stored for that cell. Otherwise it is equal to 0.
Triggering Condition for event 1C (radio link replacement)
Where, MNew is the measurement result of the cell not included in the active set. CIONew is the Cell Individual Offset for the cell becoming better than the cell in the active set if an individual offset is stored for that cell. Otherwise it is equal to 0. MInAS is the measurement result of the worst cell in the active set. CIOInAS is the Cell Individual Offset for the worst cell in the active set. H1c is the hysteresis parameter for the event 1C. Upon receiving event 1A, 1B or 1C, RNC should respond with corresponding Active Update command to instruct UE to add new cell, delete old cell, or replace exiting cell by new cell in active set. Once such command is sent, RNC will expect UE to respond with Active Set Update Complete message. If a timer defined by parameter UEActiveSetUpdateResponseTimer expires before the active set update complete message received, RNC will stop the Active Set update procedure and all resource reserved at RNC/Node for such procedure will be released (not call release!!). In Lucent, the default value of this parameter is 15 seconds. 4.3.3.5 NLSA (Neighbor List Selection Algorithm)
Lucents proprietary Neighbor List Selection Algorithm (NLSA) is used to set-up a list of the most effective pilot neighbors to be monitored by the UE, when in Cell-DCH state. This list is transmitted to UE in the RRC Measurement Control message. Its purpose is to reduce the UE's response time to detect new pilots. Assuming that the UE measured quantity is CPICH Ec/No, the main inputs to the algorithm are: The active cells list (active set); The Neighboring FDD cell information for each cell of the active set;
Network Services
The CPICH Ec/No for the active cells measured by the UE and reported to RNC in the Measurement Report messages; Cell priority group values set by a UTRAN parameter for final cell ranking.
The output of the algorithm is an ordered list of cell pilots to be monitored by the UE. The higher the ranking of a cell pilot in the list, the higher its probability is of being detected by the UE. The RNC runs the NLSA each time the active set changes following an RRC Active Set Update procedure. There are two main parameters associated with this feature: combinedNeighborhoodListSize defining the maximum number of pilots that can be included in neighbor cell list in Measurement Control message; another is neighbor cell priority parameter outFDDAdjCells.nLSAPirority. 4.3.3.6 Engineering Guidelines
This section only contains OMC accessible parameters. There are other RNC CLI accessible parameters which are not recommended to be altered from default values. For more information on these RNC CLI parameters, refer to complete parameter excelsheet in chapter 7.
4.3.3.6.1
Summary Table parameternamein database range Cingualr Default description ThresholdappliedintheRNCto determinewhichcells(fromall thosereportedbytheUEonthe RACH)arefinallytobeincluded intheactivesetatcallsetup.
TriggeringconditionsandreportingrulesCellDCHState
addThresholdSHO
0..65535
reportingCriteria1A.rcam tOfRep reportingCriteria1B.rcam tOfRep reportingCriteria1C.rcam tOfRep reportingCriteria1A.rcRe portingCriteria
reportingCriteria1B.rcRe portingCriteria
reportingCriteria1C.rcRe portingCriteria active set size
1,2,4,8,16, INFINITY 32,64, INFINITY) Maximumnumberofreportsto besentbytheUEwhenthe (1,2,4,8,16, events1A,1B,1Caretriggered.It 64 32,64, issplitinthreesubfieldsper INFINITY) eventtype (1,2,4,8,16, INFINITY 32,64, INFINITY) (0,250,500, 1000,2000, 1000 4000,8000, 16000) Itdefinesthereportperiodicity (0,250,500, whentheevents1A,1B,1Care 1000,2000, 1000 triggered.Itissplitinthreesub 4000,8000, fieldspereventtype 16000) (0,250,500, 1000,2000, 1000 4000,8000, 16000) 2.6step of1 4 Maximumsizeoftheactiveset forCSapplications
ActiveSetSizeCS
Network Services
ActiveSetSizePS reportingCriteria1A.repo rtingRange reportingCriteria1B.repor tingRange reportingCriteria1A.hyst eresis reportingCriteria1B.hyste resis reportingCriteria1C.hyste resis
2.6step of1 (0.014.5) [dB]0.5dB step (0.014.5) [dB]0.5dB step (0.07.5) [dB]0.5dB step (0.07.5) [dB]0.5dB step (0.07.5) [dB]0.5dB step (0,10,20,40, 60,80,100, 120,160, 200,240, 320,640, 1280, 2560,5000) [msec] (0,10,20,40, 60,80,100, 120,160, 200,240, 320,640, 1280, 2560,5000) [msec] (0,10,20,40, 60,80,100, 120,160, 200,240, 320,640, 1280,2560, 5000)[msec] (0.02.0) 0.1step
3 4
ReportingeventconditionrelatedparametersCellDCHState
Maximumsizeoftheactiveset forPSapplications Definesreportingrangeusedby UEforthemonitoringofprimary CPICHPrimaryhysteresisfora cellcandidatetobeeitheradded to(event1A)orremoved(event 1B)fromtheactiveset.Itissplit intwosubfieldspereventtype. Hysteresisparametertolimitthe amountofeventtirggered measurementreports.Secondary hysteresisappliedtothemain hysteresis.Itappliestoevents1A, 1Band1Canditissplitinthree subfieldspereventtype.In Event1Citistheonlyexisting hysteresis.
reportingCriteria1A.time ToTrigger
reportingCriteria1B.time ToTrigger
1280
Periodoftimebetweendetection ofeventandsendingof measurementreport. Periodoftimethatdelaysthe eventtriggering.Itappliesto events1A,1Band1Canditis splitinthreesubfieldsperevent type.
reportingCriteria1C.time ToTrigger
320
reportingCriteria1A.w
reportingCriteria1B.w
(0.02.0) 0.1step
WeightingfactorusedbyUEin conjunctionwiththereporting rangeforthemeasurement calculation.Weightingfactorfor othercellsincludedintheactive setversusthestrongestcell.It appliestoevents1Aand1Bandit issplitintwosubfieldsperevent

Network Services
type. outFDDAdjCells.cellOffs et (10.0 10.0)[dB] 0.5dBstep Offset(positiveornegative) addedtothemeasurement quantity.Itappliestoevents1A, 1Band1Conapercellbasis.
NLSA related parameter s
combinedNeighbourhoo dListSize
[1..32]
32
Maximumnumberofneighbour cellstobeincludedinthelist producedbytheNLSA.
outFDDAdjCells.nLSAPri ority
UEActive Set UEActiveSetUpdateResp Update onseTimer Response Timer
(lOW, ThisparameterdefinestheNLSA mEDIUM, mEDIUM priorityoftheneighbourcell.Itis hIGH, setonaperneighbourbasis. vERYHIGH) Ifatimerdefinedbyparameter UEActiveSetUpdateResponseTi merexpiresbeforetheactiveset updatecompletemessage (0...50000) 15000 received,RNCwillstopthe [msec]1sec step ActiveSetupdateprocedureand allresourcereservedat RNC/Nodeforsuchprocedure willbereleased
4.3.3.6.2
Engineering guidelines for SHO related parameters
Event Triggering Conditions and Reporting Rules CELL DCH State Active set size CS Parameter Name in database: ActiveSetSizeCS Access in OMC GUI: Lcell AdjacentCell tab Unit & Range: 2 to 6 step 1 Granularity: per Cell Description: This parameter specifies the number of links allowed in active set for CS call. Dependencies and constraints: Setting tradeoff: setting to low value will undermine the benefit of Soft HO as once the number of active set cell reaches this threshold, no event 1A report will be allowed. On the other hand, setting high value will cause potential excessive interference and backhaul load. High value here generally means value like 5 or 6. Engineering recommendation: 4 is believed a good value with good balance of SHO gain, system capacity and load on transport side. 2 or 1 are not considered good as it reduce the benefit of SHO Active set size PS Parameter Name in database: ActiveSetSizePS Access in OMC GUI: Lcell AdjacentCell tab Unit & Range: 2 to 6 step 1 Granularity: per Cell Description: This parameter specifies the number of links allowed in active set for PS call.
Network Services
Dependencies and constraints: Setting tradeoff: setting to low value will undermine the benefit of Soft HO as once the number of active set cell reaches this threshold, no event 1A report will be allowed. On the other hand, setting high value will cause potential excessive interference and backhaul load. High value here generally means value like 5 or 6. Engineering recommendation: 3 is believed a good value with good balance of SHO gain, system capacity and load on transport side. 2 or 1 are not considered good as it reduce the benefit of SHO. It is set less than CS case because PS call could significantly occupy backhaul capacity as in case of SHO, each involved NodeB will need to set up a Iub link with identical PS RAB. Reporting Criteria 1A Amount of Repetition Parameter Name in database: reportingCriteria1A.rcamtOfRep Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: 1,2, 4, 8, 16, 32, 64, INFINITY Granularity: per Cell Description: Maximum number of reports to be sent by the UE when the events 1A event is triggered. When UE does not receive response to 1A report, UE can continue sending same report response to 1A report, UE can continue sending same reports until this repetition limit is reached. Dependencies and constraints: Setting tradeoff: If parameter is set to a value too small, cell addition procedure may unnecessarily fail, e.g., because of lack of network resources that is only temporary but extends beyond the reporting period. Engineering recommendation: Infinity Reporting Criteria 1B Amount of Repetition Parameter Name in database: reportingCriteria1B.rcamtOfRep Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: 1,2, 4, 8, 16, 32, 64, INFINITY Granularity: per Cell Description: Maximum number of reports to be sent by the UE when the events 1B event is triggered. When UE does not receive response to 1B report, UE can continue sending same report response to 1B report, UE can continue sending same reports until this repetition limit is reached. Dependencies and constraints: Setting tradeoff: If parameter is set to a value too small, cell addition procedure may unnecessarily fail, e.g., because of lack of network resources that is only temporary but extends beyond the reporting period. Engineering recommendation: 64 Reporting Criteria 1C Amount of Repetition Parameter Name in database: reportingCriteria1C.rcamtOfRep Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: 1,2, 4, 8, 16, 32, 64, INFINITY Granularity: per Cell Description: Maximum number of reports to be sent by the UE when the events 1C event is triggered. When UE does not receive response to 1C report, UE can continue sending same report response to 1C report, UE can continue sending same reports until this repetition limit is reached. Dependencies and constraints: Setting tradeoff: If parameter is set to a value too small, cell addition procedure may unnecessarily fail, e.g., because of lack of network resources that is only temporary but extends beyond the reporting period. Engineering recommendation: Infinity Reporting Criteria 1A Reporting Interval Parameter Name in database: reportingCriteria1A.rcreportingInterval
Network Services
Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: 0, 250, 500, 1000, 2000, 4000, 8000, 16000 ms Granularity: per Cell Description: It defines the report periodicity when the events 1A is triggered. Dependencies and constraints: Setting tradeoff: If the interval is chosen too short, the UE will transmit an unnecessarily large amount of measurement reports, thereby consuming processing power in the UTRAN. If the interval is chosen too long, the reporting might not reflect the UEs environment closely, thereby inhibiting the benefits of periodic reporting after an Event 1a was detected. Engineering recommendation: 1000 ms until further trial Reporting Criteria 1B Reporting Interval Parameter Name in database: reportingCriteria1B.rcreportingInterval Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: 0, 250, 500, 1000, 2000, 4000, 8000, 16000 ms Granularity: per Cell Description: It defines the report periodicity when the events 1B is triggered. Dependencies and constraints: Setting tradeoff: same as 1A event interval. Engineering recommendation: 1000 ms until further trial Reporting Criteria 1C Reporting Interval Parameter Name in database: reportingCriteria1C.rcreportingInterval Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: 0, 250, 500, 1000, 2000, 4000, 8000, 16000 ms Granularity: per Cell Description: It defines the report periodicity when the events 1C is triggered. Dependencies and constraints: Setting tradeoff: same as event 1A case. Engineering recommendation: 1000 ms until further trial Reporting Criteria 1A Reporting Range Parameter Name in database: reportingCriteria1A.reportingRange Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0.0 14.5) [dB] 0.5 dB step Granularity: per Cell Description: Defines reporting range used by UE for the monitoring of primary CPICH Primary hysteresis for a cell candidate to be either added to the active set. Also known as R1b in formula presented in section 4.3.3.4. Dependencies/constraints: This IE shall be set consistently with respect to the parameter Weighting Event 1A (w1a, discussed later in this section) since the combination of the two affects the Event 1a triggering condition. Setting tradeoff: If parameter is set to a value too small, cells of relatively good quality may not trigger an Event 1a and will have no chance of inclusion in the active set, which may lead to poor call quality and, ultimately, a call drop. If parameter is set to a value too large, cells of relatively poor quality may trigger an Event 1a and be unnecessarily included in the active set, therefore degrading downlink capacity. Engineering recommendation: 4 dB until further trial Reporting Criteria 1B Reporting Range Parameter Name in database: reportingCriteria1B.reportingRange Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0.0 14.5) [dB] 0.5 dB step Granularity: per Cell
Network Services
Description: Defines reporting range used by UE for the monitoring of primary CPICH Primary hysteresis for a cell candidate to be either deleted from the active set. Also known as R1b in formula presented in section 4.3.3.4. Dependencies/constraints: The Reporting Range parameter for Event 1b shall be set to a value larger than the corresponding parameter for Event 1a. In addition to a difference between reporting range for 1a and 1b, an increased TTT (time to trigger) for 1b helps to avoid adding the same cell repeatedly. Setting tradeoff: If parameter is set to a value too large, cells of relatively poor quality may not trigger an Event 1b and capacity will be degraded. If parameter is set to a value too small, cells of relatively good quality may trigger an Event 1b prematurely, thereby negatively affecting call quality. Engineering recommendation: 6 dB until further trial Reporting Criteria 1A Reporting Hysteresis Parameter Name in database: reportingCriteria1A.hysteresis Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0.0 7.5) [dB] 0.5 dB step Granularity: per Cell Description: Hysteresis parameter to limit the amount of 1A measurement reports. Also known as H1a in formula presented in section 4.3.3.4. Dependencies/constraints: Setting tradeoff: If parameter is set to a value too large, measurement reporting of cells of relatively good quality may be delayed, and reporting of cells of relatively poor quality may be persistent. Instead of choosing different reporting ranges for Event 1a and 1b, the same effect can be achieved by setting the reporting ranges to equal values while adding a non-zero hysteresis. Engineering recommendation: 1 dB until further trial Reporting Criteria 1B Reporting Hysteresis Parameter Name in database: reportingCriteria1B.hysteresis Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0.0 7.5) [dB] 0.5 dB step Granularity: per Cell Description: Hysteresis parameter to limit the amount of 1A measurement reports. Also known as H1b in formula presented in section 4.3.3.4. Dependencies/constraints: Setting tradeoff: If parameter is set to a value too large, measurement reporting of cells of relatively good quality may be delayed, and reporting of cells of relatively poor quality may be persistent. Instead of choosing different reporting ranges for Event 1a and 1b, the same effect can be achieved by setting the reporting ranges to equal values while adding a non-zero hysteresis. Engineering recommendation: 1 dB until further trial Reporting Criteria 1C Reporting Hysteresis Parameter Name in database: reportingCriteria1C.hysteresis Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0.0 7.5) [dB] 0.5 dB step Granularity: per Cell Description: Hysteresis parameter to limit the amount of 1C measurement reports. Also known as H1c in formula presented in section 4.3.3.4. Dependencies/constraints: The Event 1c hysteresis should be set to a value no larger than twice the difference between the Event 1b and 1a reporting ranges, or else a cell whose quality is significantly better than that of an active set cell and is above the Event 1a triggering threshold, may not be included in the active set. Event 1c hysteresis should also never be set to 0 dB, otherwise the entering and leaving formulae may cause ping-pong for measurements that have a constant value over a period
Network Services
of time. Setting tradeoff: If parameter is set to a value too large, cells of relatively good quality may not trigger an Event 1c and will not replace cells of relatively poor quality, therefore degrading downlink capacity. If parameter is set to a value too small, cells of quality only marginally better than that of an active set cell may trigger an Event 1c, therefore increasing signaling load without appreciably improving the combined active set cells quality. Engineering recommendation: 2 dB until further trial Reporting Criteria 1A Reporting Time To Trigger Parameter Name in database: reportingCriteria1A.timeToTrigger Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000) [msec] Granularity: per Cell Description: Period of time between detection of event 1A and sending of measurement report. Period of time that delays the event triggering. Dependencies/constraints: Setting tradeoff: If parameter is too small and the Filter Coefficient IE is also set too small, monitored cells of relatively low average quality, but whose received CPICH EC/N0 exhibits rapid and large fluctuations, may trigger MEASUREMENT REPORT message transmission and be added to the active set. If parameter is too large, the UE will delay transmission of MEASUREMENT REPORT message corresponding to monitored or detected cells of relatively good quality. Engineering recommendation: 0 ms until further trial. This is intended to add cell quickly into active set to take full advantage of SHO while loading on RF and Iub are relatively low at early stage of network deployment. This is believed to help reduce drop call. This parameter should be revisited once network load increases substantially. Reporting Criteria 1B Reporting Time To Trigger Parameter Name in database: reportingCriteria1B.timeToTrigger Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000) [msec] Granularity: per Cell Description: Period of time between detection of event 1B and sending of measurement report. Period of time that delays the event triggering. Dependencies/constraints: This parameter cannot be set to very large values because it constrains the minimum setting of the equivalent parameter for Event 1c. Setting tradeoff: Measurement reporting can be reduced significantly by increasing the time to trigger (TTT) of Event 1b. In quickly fluctuating environments (Rician or Rayleigh fading at medium or large velocities), it is detrimental to quickly drop a cell (due to a low TTT for Event 1b). The link might suffer until the RNC includes the cell after an Event 1a is reported. The reduction in measurement reporting comes at the expense of a small loss in capacity as weak cells remain in the active set. Engineering recommendation: 1280 ms until further trial. This is intended to hold cells in active set a little bit longer to take full advantage of SHO while loading on RF and Iub are relatively low at early stage of network deployment. This parameter should be revisited once network load increases substantially. Reporting Criteria 1C Reporting Time To Trigger Parameter Name in database: reportingCriteria1C.timeToTrigger Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000) [msec] Granularity: per Cell Description: Period of time between detection of event 1C and sending of measurement report. Period of time that delays the event triggering. Dependencies/constraints: This parameter should be set to value no smaller than that of the Event 1b Time to Trigger, or else the following event may occur: Consider a cell whose quality drops far below the Event 1b threshold. The Event 1b timer might expire after the Event 1c timer. Before the
Network Services
Event 1b timer expires, an Event 1c may be triggered for a cell unworthy of addition to the active set but better than the cell awaiting removal (i.e. better than the cell which triggered Event 1b). In summary, a bad cell is replaced by another bad cell. Setting tradeoff: If parameter is too small, monitored cells of relatively poor average quality, but whose received CPICH EC/N0 exhibits rapid and large fluctuations, may trigger MEASUREMENT REPORT message transmission and be added to the active set. If parameter is too large, the UE will delay transmission of MEASUREMENT REPORT message corresponding to monitored or detected cells of relatively good quality. Engineering recommendation: 320 ms until further trial Reporting Criteria 1A Weighting factor Parameter Name in database: reportingCriteria1a.w Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0.02.0) 0.1 step Granularity: per Cell Description: Weighting factor used by UE in conjunction with the reporting range for the measurement calculation. Weighting factor for other cells included in the active set versus the strongest cell. See section 4.3.3.4 for more details and formula. Dependencies/constraints: This IE shall be set consistently with respect to the Event 1a and 1b reporting ranges parameter since the combination affects the Event 1a and 1b triggering conditions. Setting tradeoff: A small reduction in mean ASET size can be achieved at the expense of a significant increase in measurement reporting if W is increased from 0 to 1 and Event 1a and 1b reporting ranges are adapted to maintain capacity and call quality. Given the limited processing power of current RNCs, this tradeoff is frequently viewed as unfavorable. For a larger W and increased Event 1a and 1b ranges, the second cell is added more quickly but the third less quickly. In pilot polluted areas, the strength of the third cell may rise quickly but is not part of the active set until the RNC processed the measurement report message and issued an active set update, thus negatively affecting call quality. On the other hand, a larger W may lead to capacity increases in scenarios with large macro-diversity gains (e.g. no LOS, no frequency diversity, no time diversity = low velocity, low BLER targets) since the second cell is added more quickly. Engineering recommendation: 0 until further trial Reporting Criteria 1B Weighting factor Parameter Name in database: reportingCriteria1b.w Access in OMC GUI: Lcell reportingCriteria tab Unit & Range: (0.02.0) 0.1 step Granularity: per Cell Description: Weighting factor used by UE in conjunction with the reporting range for the measurement calculation. Weighting factor for other cells included in the active set versus the strongest cell. See section 4.3.3.4 for more details and formula. Dependencies/constraints: same as for parameter w1a Setting tradeoff: same as for parameter w1a Engineering recommendation: 0 until further trial Cell Individual Offset Parameter Name in database: outFDDAdjCells.cellOffset Access in OMC GUI: Lcell adjacentCell tab Unit & Range: (0.02.0) 0.1 step Granularity: per Cell Description: Offset (positive or negative) added to the measurement quantity. It applies to events 1A, 1B and 1C on a per cell basis. Dependencies/constraints:
Network Services
Setting tradeoff: Engineering recommendation: 0 until further trial
NLSA related parameters Maximum Neighbor Cells in combined neighbor list Parameter Name in database: combinedNeighbourhoodListSize Access in OMC GUI: LRNC handover tab soft handover table Unit & Range: 132 Granularity: per RNC Description: Maximum number of neighbour cells to be included in the list produced by the NLSA. Dependencies/constraints: Setting tradeoff: Optimal setting of this parameter should ensure that UE is monitoring a proper number of cells without excessively increasing the time spent to scan the scrambling codes. Engineering recommendation: 32 until further trial Neighbor Priority in NLSA List Parameter Name in database: outFDDAdjCells.nLSAPriority Access in OMC GUI: Lcell adjacentCell tab Unit & Range: lOW, mEDIUM, hIGH, vERYHIGH Granularity: per neighbor at cell level Description: This parameter defines the NLSA priority of the neighbor cell. It is set on a per neighbor basis. Dependencies/constraints: Setting tradeoff: Engineering recommendation: medium for all neighbors unless special need warrant different setting. At early stage of network deployment, such need is at minimal. UE Active Set Update Response Timer Parameter Name in database: UEActiveSetUpdateResponseTimer Access in OMC GUI: LRNC timers2 tab Unit & Range: (0. ..50000) [msec] 1 sec step Granularity: per RNC Description: if this timer expires before the active set update complete message received, RNC will stop the Active Set update procedure and all resource reserved at RNC/Node for such procedure will be released. Dependencies/constraints: Setting tradeoff: this timer should be set too small to prevent early termination of SHO process. Engineering recommendation: 15000 ms (15 seconds)
Network Services
4.3.4
HSDPA
4.3.4.1 Cingular Strategy
4.3.4.2 Overview
The High-Speed Downlink Packet Access (HSDPA) concept is introduced in the Release 5 of the 3GPP specification for UTRAN. The key new aspect of the HSDPA concept is to increase packet data throughput in the downlink direction with methods including link adaptation and fast physical layer retransmissions. In contrast to dedicated channels in R99, HSDPA applies a shared channel concept (aka HS-DSCH High Speed Downlink Shared Channel). Both time and code domain is shared between all HSDPA users within a cell. Multi-code transmission to one UE is allowed. Both the data rate as well as the number of channelization codes can be changed in each TTI. The TTI duration has been reduced in HSDPA to 2 ms as compared with 10 ms or 20 ms for DCH in R99. The DL common resource is shared between the different users in the cell. The resource is split in two dimensions: SF16 Codes (typically 4 codes at u03.01) 2ms timeslot The scheduler in the NodeB decides every 2ms: which users are served on the common channels How much data is sent to the UE How much power, how many common channels and which modulation scheme are used to send the data to a UE The scheduler decisions are based on: Channel Quality reported by UE (CQI) Amount of data awaiting transmission in NodeB buffer for a given UE. Priority level and other QoS parameters of each UE.
DL transmission is enhanced by the introduction of: A Scheduler a the NodeB Allows much faster adaptation to changing radio conditions than RNC (<10ms compared to 100s of ms at RNC) Adaptive Modulation sCheme (AMC). the scheduler adapts the modulation scheme (between QPSK and 16QAM) based on DL radio channel quality. (R99 only support QPSK) Hybrid HARQ. Erroneous data blocks are combined with subsequent retransmissions until data block passes CRC check. HSDPA applies retransmissions at the physical layer in the Node B in order to reduce delay. For this the terminal stores the received data packets in soft memory and if decoding has failed, the new transmission is combined with the old one before channel decoding. This HARQ strategy reduces round trip time significantly compared to R99.
Network Services
A so-called MAC-hs scheduler located in the Node B grants access for the individual users to the radio resources. To allow the system to benefit from the short-term variations, the scheduling decisions are done for HSDPA in the Node B. The idea in HSDPA is to enable transmission to the terminals when the RF conditions for the users are favorable. In the optimum scenario, the scheduling is able to track the fast fading of the users. For that purpose a new MAC-hs entity, located in the Node B has been introduced. A simplified view is shown below.
Figure 73 HSDPA UTRAN Architecture Logical channels can be mapped to a new transport channel offered by HSDPA, the so-called High-Speed Downlink Shared Channel (HS-DSCH). It is important to note that only dedicated traffic channels are mapped onto this high speed transport channel. Signaling bearers and circuit switched radio access bearers are still mapped on dedicated channels in Release 5 of the 3GPP specification.
4.3.4.2.1 Principles of HSDPA transmission

4.3.4.2.1.1 HS-DSCH Principle
Figure below illustrate the OVSF code allocation for HSDPA (example only)
SF=2 SF=4 SF=8 C16,15 SF=16 Physical channels (codes) to which HS-DSCH is mapped
NetOps-xxxxxND-00167 Rev. 1.3 06/02/06 CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions
C16,0 CPICH etc.

Network Services
Channelization codes at a fixed spreading factor of SF = 16 and allocated by Control RNC Up to 15 codes in parallel; autonomously managed by NodeB MAC-hs scheduler HS-SCCH codes with SF = 128 (number equal to simultaneous UEs) Resource sharing in code as well as time domain: Multi-code transmission, UE is assigned to multiple codes in the same TTI (2 ms) Multiple UEs may be assigned channelization codes in the same TTI Example given as below
Code
Time (per TTI) Data to UE #1 Data to UE #2 Data to UE #3 not used
Example: 5 codes are reserved for HSDPA, 1 or 2 UEs are active within one TTI Following figure illustrates the HSDPA transmission principle:
Figure 74 HSDPA transmission principle
Network Services 4.3.4.2.1.2
HSDPA transmission HARQ processes
An HARQ (Hybrid Automatic Repeat Request) process is in charge of the transmission (and possible subsequent re-transmission) of one MAC-hs PDUs PDU stands for Packet Data Unit. In HSDPA case, it is 1 Transport Block whose size is determined by scheduler based on UE category, channel condition and resource. One 2ms TTQ is allocated to each PDU per user
Once the MAC-hs PDU is sent the HARQ process waits for the ACK/NACK from the UE to decide whether to schedule a re-transmission or a new MAC-hs PDH transmission. The round trip time delay is somewhere between 6 (optimal, to be available in 03.03 release) and 7 or 8 (u03.01) 2ms-TTIs in 03.01 depending on the timing of the uplink dedicated channel In order to enable continuous DL transmission more than one HARQ process are needed (typically between 4 and 8) per UE.
Figure 75 HARQ Process
Figure 76 Soft combining with multiple HARQ processors With multiple HARQ processors, continuous transmission towards one user is made possible.
Network Services
4.3.4.2.2
Principle of HSDPA Physical Layer
The 3GPP specification introduces one new transport channel and three new physical channels for HSDPA as shown below.
Figure 77: UMTS Channels in HSDPA Since HSDPA applies a shared channel concept, soft/softer handover cannot be supported for HS-DSCH. (notice that the UL/DL signalling (DCCH), UL PS service and UL/DL CS voice/data still support and need SHO). The cell that transmits the HS-DSCH is called the serving HS-DSCH cell. The physical and transport channels introduced for HSDPA are: High-Speed Downlink Shared Channel (HS-DSCH) The transport channel HS-DSCH carries the user data in the downlink direction. The HS-DSCH is shared by several UEs and associated with a downlink DPCH for each UE to carry physical layer signaling, e.g. for UL power control, as well as higher layer signaling information High-Speed Physical Downlink Shared Channel (HS PDSCH) The physical channel HS-PDSCH is used to carry the HS-DSCH. A HS-PDSCH corresponds to one channelization code of fixed spreading factor SF = 16. A HS-PDSCH may use QPSK or 16QAM modulation. The spreading factor of 16 cannot be changed. Instead, several HS-PDSCHs can be sent to one UE within a TTI of 2 ms. High-Speed Shared Control Channel (HS SCCH) The physical channel HS-SCCH carries the necessary physical layer control information to enable decoding of the data sent on the HS-DSCH and to perform the possible physical layer combining in case of retransmissions. The HS-SCCH contains two different parts of information. The first part contains information on the modulation and the number of codes of the HS-DSCH. The second part contains information being required for successful decoding of the HSPDSCH. The spreading factor is SF = 128. High-Speed Dedicated Physical Control Channel (HS DPCCH) The physical channel HS-DPCCH carries the necessary control information in the uplink, namely, ARQ acknowledgements (both positive ACK and negative ones - NACK) and downlink channel quality indicator (CQI). DTX is also used when no ACK or NACK needed to transmit. The spreading factor is SF = 256. This channel is transmitted in the uplink for each UE. UTRAN has 3 Tx power offsets parameters: ACK, NACK, CQI to UL DPCCH to determine the transmit power of HS-DPCCH for these 3 different purposes (sending back ACK, NACK or CQI) 4.3.4.2.3 HSDPA UE Capabilities
There are 12 UE categories are defined in TS 25.306: Each UE category defines specific receiver capabilities for: Max. transport block size per TTI
Network Services
Max. number of HS-PDSCH supported Modulation capability (QPSK only / QPSK and 16QAM) Inter TTI distance (no decoding of HS-DSCH in each TTI) HARQ buffer size The MAC-hs scheduler needs to take these restrictions into account All these characteristics affect the achievable peak rate value. Maximum number of HSDSCH multicodes 5 5 5 5 5 5 10 10 15 15 5 5 Minimum inter-TTI interval 3 3 2 2 1 1 1 1 1 1 2 1 Maximum MAC-hs TB size (bits) 7298 7298 7298 7298 7298 7298 14411 14411 20251 27952 3630 3630 Theoretical maximum PHY data rate (Mbit/s) 1.2 1.2 1.8 1.8 3.6 3.6 7.2 7.2 10.1 14 0.9 1.8
HS-DSCH Category Category 1 Category 2 Category 3 Category 4 Category 5 Category 6 Category 7 Category 8 Category 9 Category 10 Category 11* Category 12*
*: category 11 and 12 only support QPSK mode. All other categories support both QPSK and 16QAM 4.3.4.2.4 HSDPA Service Combinations
Lucents 03.01 UTRAN supports the following service combinations with HSDPA in the downlink direction.
Figure 78 Service Combinations for HSDPA
Network Services
4.3.4.3 NodeB Capabilities and Configuration

The maximum number of HSDPA users in a cell and the peak data rate that is supported by a cell and offered to a HSDPA user depends on the number of UCU boards the Node B is equipped with. In u03.01 release only UCU-II boards are used. 4.3.4.3.1 UCU-II Channel Card
Each UCU-II board has eight Channel Element Devices (CED) doing the signal processing for common channels, R99 and HSDPA channels. A channel element device being used for R99 or HSDPA can support only channels of the same configuration type (i.e. either R99 or HSDPA). If a channel element device is configured for HS-PDSCH, it can serve up to four HS-PDSCHs. In the UCU-II architecture, a CED cannot be allocated to support both dedicated and common channels. Any spare capacity on a CED allocated to common channel would be unused. Therefore a significant gain can be achieved through reducing the common channel overheads onto a single CED. Note that the call with the smallest spreading factor (SF) determines the capacity on a CED. For example, if a packet data call with DL 64kb/s and UL 64kb/s plus a voice call are processed on the same CED that CEDs capacity is determined by the 64kbps packet data call. There is therefore the possibility that although there maybe some room to accommodate a new incoming call, a low SF call can be blocked or dropped even when some CEDs are not fully utilized. For the configuration of the Node B two models are offered, the so-called small and large model. Following table summarizes the Node capacity for both configuration models. Node B Capacity Table Number of UCU-II boards Peak Data Rate per Cell Peak Data Rate per User Maximum Number of HS-SCCH per Cell Maximum Number of HS-PDSCH per Cel Maximum Number of HSDPA users per Cell Small Model 2 3.715 Mbps 3.715 Mbps 8 8 8 Large Model 3 -- 12 11.145 Mbps 7.6 Mbps 8 12 24
Table 25 NodeB Capacity Table Such model is selected by NodeB level parameter hsdpaResourceAllocationScheme. Note: small and large model can be used for any number of UCU-II boards from 1 12, however, typically they are used for the number of boards in the table Independent of the number of UCU-II cards the Node B is equipped with; the Node B can be configured with either of the two models. The number of HSDPA and R99 users that can be simultaneously served by the two configurations depends on the number of UCU-II boards as well as on the data rate of the associated uplink DCH. For any Node B configuration the number of simultaneously active HSDPA users is limited to at most 24 users per sector. The peak data rate throughput would also be a factor of the backhaul T1 capacity along with the model type. 4.3.4.3.2 HSDPA Dimensioning Rules
The following dimensioning rules are applied for HSDPA, using UCU-II. The chosen HSDPA user capacity and throughput values are constrained by limitations of the DSP and/or Power PC processing power. Each UCU-II has 8 CEDs
Network Services
1 UCU-II is required to support R99 traffic and the signaling overhead channels (i.e., RACH/FACH etc. requires 1 CED per sector). Each CED can support 8 HS-PDSCH (users) Per sector, 0.5 or 1 HS-SCCH CED and 1, 2 or 3 HS-PDSCH CED(s) can be configured. Typically, one HS-SSCH CED can be used to serve one sector. The special case of a 0.5 HS-configuration with only 2 UCU-IIs (instead of 3) is possible, however the data rates are reduced in this case to 3.7Mb/s per sector. Configurations with 1HS-PDSCH CED are sometimes called small and those with 3 HS-PDSCH CEDs large configuration. A single HSPDSCH CED supports a peak rate of 3.715 Mb/s to a single user One UCU-II has the processing capacity of supporting up to 24 HSDPA users and an aggregate peak rate per sector of 11.145 Mb/s. A CED dedicated to HSDPA can not share resource with R99 calls. The CED can be reassigned to R99 CED through NBAP signaling (requires NodeB reset). Vice versa, a CED defined as DCH CED can not handle HS DSCH portion of HSDPA call but can process the DCH Portion. Number of HSDPA Users Supported
4.3.4.3.3
The number of HSDPA users supported is: The minimum of the product sectors multiply by HS-PDSCH and the number of uplink legs based on CED available for uplink dedicated channels. If both HSDPA and R99 traffic are to be present, then in addition to the CEDs accounted for the dedicated uplink leg of an HSDPA users, additional CEDs for R99 traffic have to be present. A HSDPA + R99 traffic mix will typically reduce the HSDPA user capacity if the number of UCUs is kept constant. Additional UCU resources may be needed to avoid a reduction in the HSDPA user capacity. 4.3.4.3.4 03.01 Deployment
In 03.01 and initial Cingular deployment, only small model (see section 4.3.4.3.1) is used, i.e. only 2 UCU II cards are deployed in each site (3 sectors). This capacity will allow 24 users per Node B (8 per sector in a 1c 3s Node B configuration) with 64K UL for the small model (1 PDSCH per sector). If we require UL at 128K then a third UCUII would be essential to support 24 users per Node B. For the large model, this number changes to 5 UCU II cards for 64Kbps UL and 7 UCU II cards for 128 Kbps UL respectively. Following figure illustrates the typical configuration of CED with HSDPA enabled in the cell.
Figure 79 CED configuration with UCU II and HSDPA 2 UCU IIs cards per NodeB configuration Maximum of 4 HS-PDSCH (SF16 codes) per cell Max number users on HSDPA scheduler: 8 per cell.
Network Services
For further details on UCU II and future version UCU III (which will be needed to support 03.03 software), go to this link on Network Connection Point: Lucent_UCU II_engineering and UCU III technical document and engineering guideline For more information on 03.01 and UCU II, see 03.01 HSDPA Implementation Guide section 3.2 at 15161_Cw_Lu_HSDPA Implementation Guide 1[1].1
4.3.4.4 Code and Power Allocation

4.3.4.4.1 Code Allocation for HSDPA and Interaction with R99
HSDPA offers in the downlink direction the physical channels HS-PDSCH and HS-SCCH. The first one requires a channelization code of length 16, the second one a channelization code length of 128. Since the codes are allocated to these channels in the Node B, the RNC informs the Node B via NBAP signaling which part of the channelization code tree can be used for HSDPA. There are three main parameters related to code allocation: 1. 2. hSDSCHStartCode: this parameter states the number of the first channelization code of SF = 16 used for HSDPA. This is a cell level parameter. numberOfHSDSCHcode: it sets the number of HS-PDSCH codes. Also a cell level parameter.
Together, hSDSCHStartCode and numberOfHSDSCHcode define the complete list of SF 16 codes from OVSF code tree that will be used for HSDPA call (HS DSCH). For instance, if start code = 12 and number of code = 4, then Code 12, 13, 14, 15 will be allocated (exclusively) to HS DSCH. Since there are only 16 SF16 codes, the sum of these two parameter values must be equal or less than 16. 3. hSCCHcode: This parameter hSCCHcode sets both the number of HS-SCCH channels per cell as well as the number of channelization codes to be used for HS-SCCH within the code tree. It is a cell level parameter presented in sequence integer format with length of 4. For instance, {3, 8, 9, 10} means OVSF code 3, 8, 9, 10 at SF = 128 level will be reserved for HS SCCH. Lucent default is {3, 8, 9 10} and it is chosen to maximize the orthogonality. For such purpose, this default should be kept as is.
In 03.01, the codes allocated to HSDPA can not be used for R99 traffic. This is also known as Static HSDPA Code Allocation. A dynamic HSDPA code allocation is available in future 04.03 release.
4.3.4.4.2
Power Allocation for HSDPA and interaction with R99
RNC informs the Node B via NBAP signaling on the maximal power to be allowed for all codes used for HS-PDSCH and HSSCCH. The parameter for setting the power allocation is hSPDSCHSCCHpower. Machs scheduler then distribute the allocated power efficiently over all HS-PSDCH and HS-SCCH to be transmitted. Note that, the HSDPA power allocation is independent on R99 user in u03.01. A HSDPA always gets the full power that has been allocated to HSDPA if at least one HSDPA user is active. So its either full or nothing method. If R99 invades into HSDPA territory (for instance, due to no HSDPA users when a lot R99 users get on the cell first) the PA runs into overload and AOC (Aggregated Overload Control) starts to scale down both R99 and HSDPA and eventually provides full reserved power to HSDPA user. On the other hand, if there is no active HSDPA user, R99 traffic could use the reserved power. This is demonstrated in figure 80 shown below:
Network Services
Figure 80.
03.01 HSDPA Power allocation
Apparently, it is wise not to define the hSPDSCHSCCHpower parameter to a large value as the DL load includes the active HSDPA Power which artificially increase the calculated load result. This could lead to blocking of DCH traffic. See section 4.3.4.5.2 for more info. This semi-fixed reservation behavior will be changed in upcoming release 03.03 where HSDPA can use more power if R99 traffic is low, if HSDPA scheduler needs more power for multiple users. When R99 traffic gets on, HSPDA traffic will scale back. In principle, priority is given to R99 traffic in 03.03, i.e. R99 traffic can also use reserved power for HSDPA if there is no active HS user (same as 03.01).
4.3.4.5 Radio Resource Management

4.3.4.5.1 RAB setup (Admission Control)
RRC connection setup and RAB setup are largely unchanged compared to R99 only traffic. Additional IE (information element) are added into RRC connection request message to indicate UEs new capabilities for HSDPA (UE category and support of HSDPA). Since Rel. 5 still requires control panel signaling to be served on DCH instead of HS-DSCH, a HS_DSCH transport channel requires an associated DCH transport channel in DL direction. Uplink is unchanged from R99. see figure in 4.3.4.2.2. for illustration. NodeB will continue accepting HS users until maximum number of HS-DSCH users is reached. This limit is set by a cell level parameter maxHsdpsUserPerCell with default of 24. with more users get on the cell,
Network Services
power given to each user will reduce. This is decided by scheduler based on priority of the user aka. Traffic Handling Priority (THP) and RF conditions. There are 3 level of Interactive and 1 level of background defined by 3gpp QoS spec. Interactive is higher than background. Note that if small mode is chosen for the cell (section 4.3.4.3.1), maxHsdpaUserPerCell parameter should be set to 8 or less.
4.3.4.5.2
Load control (DBC and CongC)
Downlink load control applies to the associated downlink DCH. A HSDPA call request is blocked if no resources are granted for the associated downlink dedicated channel. The HS-DSCH transport channel itself does not undergo the load control procedures. For downlink load control in 03.01 for dedicated channels no distinction between HSDPA power and nonHSDPA power is made. (Refer to chapter 4.3.1 for more details on Load Control).This means that the total transmit sector power is used as a criterion for load control. In another word, even there is no DCH traffic, the DL load will be considered exist as (active HSDPA power + Common Control channel power) / total PA power instead of just common channel power / total PA power. This artificially raises the load on DL. Therefore hSPDSCHSCCHpower should not be set to too high values in order to avoid blocking of dedicated channels. For the associated uplink DCH, the uplink load control framework is applied. In uplink direction for HSDPA only the call admission control and congestion control checks are implemented in 03.01 since DBC for UL is not available until 03.03 release. Depending on the requested uplink data rate the appropriate thresholds are applied. Rate negotiation is not available in 03.01 (i.e. if a requested 128k RAB is denied the call request is rejected). A 64k RAB call admission control check does not take place in u03.01 once the 128k check fails. 4.3.4.5.3 Scheduler Algorithm (Physical layer procedure)
The MAC-hs layer and the physical layer of HSDPA go principally through the following steps: 1) Every 2ms, the MAC-hs scheduler in the Node B evaluates for all active users what the channel conditions are, how much data is pending in the priority queues for each user, how much time has elapsed since a particular user was last served, for which user retransmissions are pending and so-forth. a. UE measures the instantaneous RF conditions and reports the quality of the channel by sending the channel quality indicator (CQI) on the HSDPCCH back to the Node B. CQI is determined by UE with UE proprietary algorithm compliant with 3GPP standards. b. The goal of CQI reporting is to maintain the DL BLER below 10%, i.e. if NodeB transmits data using parameters suggested by CQI, DL BLER should be 10% or less. This is set by 3gpp standard. c. CQI will determine multiple parameters to be used for HS-PDSCH transmission: transport block size, number of HS-PDSCHs, modulation scheme, power offset of HS-PDSCHs.
The 3GPP specification (25.214) defines the meaning of the reported CQI values for each UE category. In spec. 34.121 the requirements for the accuracy of the channel quality measurements are given. According to 25.214, the UE shall assume, for the purpose of CQI reporting, a total received HS-PDSCH power of
PHSPDSCH= PCPICH + + in dB
Network Services
where the total received power is evenly distributed among the HS-PDSCH codes of the reported CQI value. is the measurement power offset signaled by the RNC, defined by RNC level parameter hSDPAMeasurementPowerOffset. Recommended value is 6 dB. is the reference power adjustment given for each UE category. See table 7A, 7B, 7C, 7D, 7E (table 7E is for category 11 or 12 which is the current model Cingular sells in year 05/06) in 25.214. PCPICH is the transmit power of the P-CPICH or the S-CPICH. hSDPACQIFeedbackCycleK: this will determine how often CQI is reported hSDPACQIRepetitionFactor: determines how many times the same CQI value is reported (repeat time = Repetition Factor -1). This can be used to alleviate the extreme fluctuation of CQI values in successive frames. Example: if CycleK = 10 ms and Repetition Factor = 3, then following applies (keep in mind HSDPA TTI = 2ms):
d. Frequency of CQI reporting: this is determined by two parameters (RNC level in Lucent):
Figure 81. CQI/ACK/NACK report repetition In Lucent 03.01 release, only CycleK = 2 ms and CQI Repetition Factor = 1 are supported. This effectively requires UE to report CQI every 2 ms and only report once. Future release to support other CycleK value other than 1 has not been committed yet.
2) Once it has been determined which terminals can be served in a particular TTI, the Node B identifies the necessary HS-DSCH parameters (based on CQI reported). This includes how many codes can be used, whether 16QAM modulation is applicable and what the terminal capability limitations are. Also the transmit power for HS-DSCH and HS-SCCH is determined. 3) The Node B starts to transmit the HS-SCCH to inform the terminal of the necessary parameters. Each terminal listens to at most 4 HS-SCCHs. 4) The terminal monitors the HS-SCCHs given by the network and once the terminal has decoded the first part from a HS-SCCH intended for that terminal, it starts to decode the rest of that HS-SCCH. 5) Upon having the HS-SCCH parameter decoded from the second part of that signaling channel, the terminal can determine to which HARQ process the data belongs and whether it needs to be combined with data already in the soft buffer. a. Category 6 UE supports 6 HARQ processors; category 11 supports 3
Network Services
6) Once the decoding of the potentially combined data is completed for the HS-DSCH, the terminal sends in the uplink direction an ACK/NACK indicator, depending on the outcome of the CRC check conducted on the HS-DSCH data. a. Repetition of ACK/NACK: similar to repetition of CQI reporting, ACK/NACK messages can be repeated if needed. In Current 03.01 release, only repetition factor = 1 is supported (parameter hSDPAACKNACKRepetitionFactor). So no repeated ACK/NACK messages are required. If the message is not received, higher layer (RLC) will take care of retransmission. b. Power of HS-DPCCH: transmit power of HS-DPCCH is tied to transmit power of DPCCH (used for DCH). Similar to weighting factor used for DPDCH vs.DPCCH (i.e. c and d as described in chapter 4.3.2. Power Control section 4.3.2.9.1 or chapter 4.2.2. RACH Procedure section 4.2.2.3.4.), a hs weighting factor is introduced for HS-DPCCH power setting: The relative power offsets ACK, ACK and CQI are quantized into amplitude ratios as shown in Table below: The quantization of the power offset
Signalling values for ACK, ACK and CQI 8 7 6 5 4 3 2 1 0 Quantized amplitude ratios for
10
30/15 24/15 19/15 15/15 12/15 9/15 8/15 6/15 5/15
HS DPCCH 20
HS DPCCH : HS-DPCCH power

offset in dB relative to DPCCH power 6.0 4.1 2.1 0.0 -1.9 -4.4 -5.5 -8.0 -9.5
Table 26 HS-DPCCH power offset Lucent s default is 5. This has been recommended to be changed to 6 (i.e. 2 dB higher power given to HS-DPCCH) based on the fact that since HSDPA call only has one uplink HS_DPCCH towards HSDPA serving cell while UL DPCCH can be linked to multiple cells in SHO situation, it is likely that the UL DPCCH leg associated to the HSDPA serving cell could be weaker than another UL DPCCH associated to other cells in Active set. When this difference increases to level beyond 3 dB, HS-DPCCH transmission error will raise rapidly. A few reasons for such imbalance among different legs: uneven CPICH power, fading, or hardware fault. By using value 6 for this parameter (2 dB higher power given to HS-DPCCH) it is believed the HSDPCCH error can be reduced without significant UL Interference increase caused by higher power on HS-DPCCH, therefore improve overall HSDPA throughput.
(note: the current 03.01 Lucent HSDPA TAN gives wrong information in table 13. User should discard the 5 dB values in the Unit column) 7) If the network continues to transmit data for the same terminal in consecutive TTIs, the terminal will stay on the same HS-SCCH that was used during the previous TTI. The HSDPA processing flow starts with (1) in the next TTI again. Priority Queue and HARQ Handling
Once a MAC-d PDU is sent to the Node B, it resides in the priority queue till it is transmitted within a MAChs PDU over the air interface by the HARQ protocol. A timer called hsdpa discard timer is introduced to
Network Services
limit the dwell time of the MAC-d PDUs in the priority queue in NodeB. The Node B shall use this information to discard out-of-data MAC-hs SDUs from the HSDPA Priority Queues. When the timer expires, the PDU is discarded. I.e. the timer puts a hard limit on queuing delay at the cost of discarding PDUs. These PDUs must then be retransmitted by RLC. In order to avoid excessive RLC retransmissions, the timer value should be high as compared to the typical queuing delay in normal operation, which is in the order of 30...100ms. Suggested default value of 2000 ms should prevent the timer expires in normal operation. Only in situations where MAC-hs throughput drops significantly for a longer period of time, e.g. during a cell change in bad conditions, the timer would start to discard PDUs. ON UE side, 3 main function units work in sequence to deliver data from Mac-hs layer to Mac-d layer (then to higher layers like RLC): HARQ, Reordering and Disassembly. The HARQ entity is responsible for generating ACK or NAK responses to received packets. The Re-order Queue Distribution routes packets to the correct reordering queue based on Queue ID. This supports multiple services requesting data over the HSDPA feature. The reordering entity is responsible for collecting consecutive PDU based on the Transmission Sequence Number (TSN). MAC-hs PDU will not be forwarded to the disassembly function until all missing PDU units with lower TSN assignments have been received. The disassembly entity is responsible for removing the MAC-hs header and all padding bits. The MAC-d PDUs extracted from the payload are forwarded to the MAC-d for processing.
To MAC-d MAC-hs
Disassembly Reordering Disassembly Reordering MAC Control
Re-ordering queue distribution
HARQ
HS-DSCH
Associated Downlink Signalling HS-SCCH
Associated Uplink Signalling HS-DPCCH
Figure 82 Mac-hs functions in UE
With these 3 units, two parameters are introduced to control the retransmission of erroneous PDUs: T1 timer and Window Size: T1 Timer:
Network Services
T1 timer limits the dwell time of a MAC-hs PDU (and hence of a MAC-d PDU) in a HARQ process. The timer T1 is started for an outstanding MAC-hs PDU (i.e. unacknowledged) as soon as MAC-hs PDUs with higher sequence number (i.e. newer PDUs) are correctly received in the reordering unit. After expiration of the timer T1, the correctly received MAC-hs PDUs are reordered and delivered to the disassembly unit and the outstanding MAC-hs PDUs are discarded in the UE. At UTRAN side a HARQ process stops retransmitting a MAC-hs PDU if the PDU is not acknowledged after the time T1 from the instant of the first transmission of this PDU. In Lucent, T1 is defined by parameter hSDPAT1. Default is 200 ms. Mac-hs Window Size The UE (Rx end) monitors the difference between the sequence numbers (SN) of already correctly received MAC-hs PDUs and the SN of those MAC-hs PDUs that are still outstanding. If the difference exceeds the MAC-hs window size the outstanding MAC-hs PDUs are discarded as well, i.e. these PDUs will be removed from soft buffer of the UE. On UTRAN side (Tx end), the UTRAN stops retransmitting an outstanding MAC-hs PDUs if the SN of a transmitting MAC-hs PDU waiting for an ACK plus the window size exceeds the current SN of a new MAC-hs PDU. New PDUs are only transmitted till the transmit window is filled up and old PDUs are retransmitted at MAC-hs till the maximal number of HARQ transmissions (4 in Lucent) is achieved or the T1 timer expires. See 25.321 for more details. In Lucent, Tx and Rx window size is given same value and only one parameter is defined hSDPAMacHsWindowSize. Default is 32 (32 Mac-hs PDUs). T1 and Window size together control the retransmission of unacknowledged Mac-hs PDUs. They shall make sure that a MAC-hs PDU is not retransmitted too often while they should not be set too small either in order to avoid that the transmissions stop. For example if a MAC-hs PDU needs to be retransmitted a couple of times, it takes about 16ms for UCU-II (and 12ms for UCU-III) till a NACK is received. If T1 timer is set to 50ms at most, then only 3 HARQ retransmissions (floor(50/16) = 3) would be allowed by the Node B before the HARQ process is reset.
4.3.4.6 State Transition with HSDPA

4.3.4.6.1 Call setup
The call setup for HS-DSCH follows the same procedure used for DCH. (see chapter 4.3.1) The call will set up on HS-DSCH instead of DCH if all following conditions are fulfilled: UE supports HS-DSCH (checked by RNC through RRC connection request message) Cell supports HS-DSCH o o RNC allows HSDPA: parameter hSDPAActivation = TRUE Cell support HSDPA: parameter cellResource.hsdpaCapable = TRUE.
RAB established rate > = minimum DL Rate for HSDPA defined by parameter minRateForHSDSCH (default: 33 kbps)
Network Services
Low UE Mobility see section 4.3.6.7 for details. Resources available on HS-DSCH i.e. max # users not exceeded (# of active HSDPA users < = parameter maxHSDPAUserPerCell) (default: 8 for small model NodeB)
For associated Uplink DCH, it follows the same procedure as normal R99 traffic (i.e. either 128 or 64 depending on RAB request from UE). A parameter is used here to configure the initial Uplink data rate for HSDPA call initialHsdpaUplinkRateRABEstablish, default is 128 kbps. (64 kbps is another possible value in 03.01. more values will be available in 03.03).
4.3.4.6.2
State transition
State transition between HS DSCH and CELL_FACH, URA_PCH and Idle follows the same procedure used for DCH described in chapter 4.3.1. No special parameter added for transition from HSDSCH or DCH to other states. For transition between DCH and HS-DSCH, following procedure applies: HS-DSCH to DCH trigger: if one of the following conditions is met: High mobility see section 4.3.4.7 for more details Intra RNC serving cell change in case of target cell not supporting HSDPA Inter RNC (over Iub) SHO Simultaneous CS/PS call and inactivity on PS bearer occurs o Transition to 8k/8k DCH
DCH to HS-DSCH triggers High mobility going to low mobility (see section 4.3.4.7) Handover from a Cell not supporting HSDPA to one that does Radio link Failure of Serving HS-DSCH cell UE at 8kbps being reconfigured up
Timers for State Transition between DCH and HSDSCH Transition between DCH and HSDSCH involves Radio Bear Reconfiguration procedure to activate new radio bearer. As shown in figure 83 below, which is an example for HSDSCH DCH transition, RNC will synchronize NodeB and UE by sending activation timer (Tactivation in the figure) to NodeB (through Radio Link Reconfiguration Commit) and UE (through Radio Bearer Reconfiguration). The reference point of this timer is the time RNC receives Radio Link Reconfiguration Ready message from NodeB. RNC then use RNC RLI parameter hSDSCHDCHCommitLatencyTimer (Default is 650 ms) to calculate the activation time. This time is communicated to UE and NodeB in CFN (connection frame number) format. Since CFN is commonly known to both UE and NodeB, NodeB and UE will follow this activation timer to simultaneously activate new radio bearer (in example case, DCH bearer).
Network Services
Similarly, DCH at 650 ms.
HS-DSCH transition has a timer called dCHHSDSCHCommitLatencyTimer, defaulted
Both DCH to HSDSCH and HSDSCH to DCH transition are guarded by a timer initially set to the value tDCHHSDSCH. This timer starts in the RNC as soon as the RRC message RADIO BEARER RECONFIGURATION has been sent to the UE. If the RRC message RADIO BEARER RECONFIGURATION COMPLETE has not been received until the guard timer expires the PS bearer is released. The additionally introduced timer hSDSCHToDCHReconfigurationProcedureTimer supports the HSDSCH _ DCH reconfiguration as well. For DCH _ HS-DSCH reconfiguration the timer dCHToHSDSCHReconfigurationProcedureTimer is used. Their function is to completely clear the process once the PS bearer is already released. They are additional saftey timers to clean up the procedure in case of faulty behavior (without them, in case of faulty behavior the processes could stay in memory until the RNC runs out of memory). They are not added to tDCHHSDSCH : For instance, and with the default values 3 seconds of tDCHHSDSCH and 100 seconds for these two procedure timers, if the reconfiguration process lasts more than 3s and somehow the PS bearer fails to be torn down then, it will be torn down after the 100th second.
Figure 83 HSDSCH
DCH transition procedure
4.3.4.7 Mobility
4.3.4.7.1 Intra RNC HSDPA Serving Cell Change
The UE uses soft handover for the uplink, the downlink DCCH and any simultaneous CS voice or data. Therefore, event 1A, 1B, 1C will still be seen.
Network Services
For HS-DSCH channel, one new event 1D is introduced. Two new parameters hSDPASrvCellChgCrit.timeToTrigger and hSDPASrvCellChgCrit.hysteresis are used to control the cell change. Similar to SHO time to trigger and hysteresis, the timeToTrigger is a delay during which 1D condition is fulfilled continuously before the cell change can be triggered. Hysteresis is specifies the hysteresis value between serving cell CPICH and new pilot CPICH. They are illustrated in following figure 84:
Measurement quantity CPICH 1

Hysteresis
CPICH 2
CPICH3
Time to trigger
Reporting event 1D
Time
Figure 84 HSDPA Serving Cell Change hSDPASrvCellChgCrit.hysteresis has default of 1 dB. Recommended value is 3 dB. hSDPASrvCellChgCrit.timeToTrigger has default of 320 ms. Recommended value is 640ms. Also, two other new parameters are added to help further manipulate the traffic: hSDPASrvCellChgCrit.useCIO: if set to TRUE, CIO of neighbor cells can be used to adjust the hysteresis, similar to the CIO parameter used for SHO and IRAT. Default is TRUE. outFDDAdjCells.cellOffset: defined CIO value for individual cells. Default is 0 dB for all cells (no difference among all neighbors) Timer for HSDPA Cell Change
Similar to timer used in State transition (section 4.3.4.6), certain timers exist in RNC to monitor and control the cell change procedure. In Cell change case, Transport Channel Reconfiguration procedure is used if Cell Change is inter-NodeB. If intra-NodeB cell change is the case, same transport channel will be used.
Network Services
For Inter-NodeB cell change: when RNC receives the Radio Link Reconfiguration Ready message from all involved NodeBs, RNC will determine the activation time for UE and source and target NodeB to do synchronized transport channel change. This activation time is calculated by using the time when needed Radio Link Reconfiguration Ready messages are received from both source and target NodeB, and a parameter srvHSDSCHCellChgCommitLatencyTime. Then this activation time is communicated to both NodeB and UEs to ensure simultaneous activation of new transport channel. There is another parameter used to control the stopping of transmission to old (source) NodeB in this process. It is minTimeStopSchedSrvHSDSCHCellChg. Default is 100 ms. This time is referenced to the activation time of new transport channel as described above. If not all MAC-d PDUs can be transmitted till the committed activation time, they need to be retransmitted by RLC. Apparently this parameter should not be set too large, otherwise unnecessary RLC retransmission will occur which will reduce application throughput. Similar to State transition, a guard time is available at RNC level to oversee the cell change procedure. It is called srvHSDSCHCellChgeGuardTime. While the timer is running the RNC discards any events of type 1A, 1B and 1C for this UE and stores the newest event 1D. This timer must be greater than (srvHSDSCHCellChgCommitLatencyTime + some time for the NBAP radio link reconfiguration procedure and the receipt of the RRC message TRANSPORT CHANNEL RECONFIGURATION COMPLETE ). The guard time should not be chosen too large since all soft handover events are blocked as long as the timer is active. If the guard timer expires before the RNC received the RRC message TRANSPORT CHANNEL RECONFIGURATION COMPLETE than the PS bearer is released. Default of this Guard Time is 10 seconds. 4.3.4.7.2 Inter RNC HSDPA Serving Cell Change
In 03.01, Inter RNC HSDPA Cell Change is not supported since this involves Iur interface and 03.01 does not support RRC state change over Iur. If the new cell belongs to different RNC, a HSDSCH DCH transition is executed. DCH 384 RAB will be allocated in such case. Similar radio bear reconfiguration described in 4.3.4.7.1 will be used. If UE handover back to SRNC (service RNC) cell from DRNC (Drift RNC) cell with the same RRC connection (i.e. no RRC call release), UE will resume HSPDA bearer in SRNC. If for some reasons (RF condition for example) the RRC connection is released in DRNC, as long as PDP context is still active and data session continues (for example a FTP download) the UE will re-establish the RRC connection in DRNC. For the newly setup RRC connection, previous DRNC will become new SRNC and the call will be setup on HSDPA bearer 4.3.4.7.3 Mobility Monitoring and handling
Too many serving HS-DSCH cell changes within a short period of time may cause a reduced throughput and a loss of data. In this case it is beneficial to carry the PS connection over DCH rather than HS-DSCH. For this purpose the number of HS-DSCH cell changes is tracked by the UTRAN. If this number exceeds an unusual amount of serving cell changes, the call is changed from HSDSCH to DCH. The decision algorithm is described in more detail in the sequel. If a call is setup for a HSDPA capable terminal a so-called mobility timer status hSDPAMobilityTimer is initialized to a configurable parameter hSDPAMobilityThreshold. Default is 5 seconds. Recommended value is 1 second.
Network Services
Each second this timer is decremented by one (1) as long as it is positive. Depending on the RRC state of the connection, the timer is incremented by hSDPAMobilityThreshold when certain events occur. In CELL_DCH state the timer is incremented each time an event 1D is received. In CELL_FACH state the timer is incremented when a cell reselection is executed. The timer hSDPAMobilityTimer is capped to the product of the configurable parameters hSDPAMobilityThreshold * hSDPAMobilityMaxFactor. Recommended value of the latter is 10, so the hSDPAMobilityTimer is capped at 1 * 10 = 10 seconds.
If a RRC state transition from CELL_FACH to CELL_DCH is triggered the current status of hSDPAMobilityTimer is used to decide for a HSDPA capable terminal whether the call is established on HS-DSCH or DCH: If hSDPAMobilityTimer < = hSDPAMobilityThreshold the call is established on HS-DSCH, otherwise on DCH.
If in CELL_DCH state hSDPAMobilityTimer increases it indicates that serving HS-DSCH changes are executed. If too many cell changes occur a HS-DSCH DCH change is executed. The criterion for this is: hSDPAMobilityTimer > = hSDPAMobilityThreshold * hSDPAMobilityDCHFactor Recommended value of the hSDPAMobilityDCHFactor is 9.9. So HS-DSCH occur when mobilityTimer goes above 1 * 9.9 = 9.9 seconds. DCH change will
The timer is decreased each second. If the rate of decrease is larger than the rate of increase it indicates that the amount of serving HS-DSCH cell changes is tolerable again: A DCH _ HS-DSCH change is triggered if hSDPAMobilityTimer = 0
Following diagram illustrate these concepts:
Figure 85 HSDPA Mobility Scenario 1
Network Services
timer increment of HSDPA_mobility_thr eshold seconds
Timer value
Figure 86 Mobility Scenario 2
4.3.4.8 Engineering Guidelines for HSDPA Related UTRAN Parameters

4.3.4.8.1
4.3.4.8.1.1
Summary table
HSDPA Configuration Parameters
Parent Object LRNC
Parameter Name hsDPAActivation
Recommend ed Setting TRUE
Range True/False small model large model 0.0 to 50.0 (in 0.1 dB steps) 1 to 15 1 to 12 0 to 127
Short Description The HSDPA feature can be turned on or off at the RNC level by this parameter This parameter allows choosing the Node B configuration. Per default the small model is selected. Maximal transmit power for all HSDPA channels Number of the first SF=16 code used for HSDPA Number of SF=16 codes reserved for HS-DSCH Number of SF=128 codes reserved for HS-SCCH Maximal number of HSDPA users per cell. There is an interaction with the Node B Configuaration. This parameter sets the measurement offset used in the terminal.
LNodeB
hsdpaRecourceAllocationSch eme
Lcell: HSDPA Lcell: HSDPA Lcell: HSDPA Lcell: HSDPA Lcell: HSDPA
hSPCSCHSCCHpower hsDSCHStartCode numberOfHSDSCHcode hSCCHcode
42 [dBm] 12 4 {3, 8, 9, 10}
maxHsdpaUsersPerCell
24
0 to 32 {-6, 5.5,,13} dB
LRNC
hSDPAMeasurementPowerOf fset
6 [dB]
Network Services
Table 27: HSDPA Configuration Parameters

4.3.4.8.1.2 MAC-hs Parameters
Parent Object
Parameter Name
Recommended Setting
LRNC
hSDPADiscardTimer
0 [ms]
Range 0; 20 ; 40; 60; 80; 100; 120; 140; 160; 180; 200; 250; 300 ; 400; 500; 750; 1000; 1250; 1500; 1750; 2000; 2500; 3000; 3500; 4000; 4500; 5000; 7500 10; 20; 30; 40; 50; 60; 70; 80; 90; 100; 120; 140; 160; 200; 300 ; 400
Short Description Maximal dwell time of a MAC-d PDU in the priority queue. After that time the PDU is discarded. A default value of zero indicates that the allow dwell time is infinity.
LRNC
hSDPAT1
200 [ms]
Expiration time when outstanding MAC-hs PDUs are discarded in the terminal.
LRNC
hSDPAMacHsWindowSi ze
32 [Number of MAChs PDUs]
4; 6; 8; 12; 16; 24; 32
TX window size of the Hybrid ARQ
Table 28: MAC-hs Parameters

4.3.4.8.1.3 Physical Layer Parameters
Parent Object Lcell: ULDPCHInfo Lcell: ULDPCHInfo Lcell: ULDPCHInfo
Parameter Name hSDPAACKpowerOffset hSDPANACKpowerOffs et hSDPACQIpowerOffset
Recommend ed Setting 6 6 6
Range
Short Description Power offset of ACKs relative to the UL DPCCH power. Power offset of NACKs relative to the UL DPCCH power. Power offset of CQI values relative to the UL DPCCH power. Repetition factor of ACKs and NACKs. Per default the ACK/NACK is not repeated. In 03.01 only the default selection is supported. Feedback cycle of CQI values. Per default the CQI is transmitted in each TTI of 2 ms. In 03.01 only the default value is supported.
LRNC
hSDPAACKNACKRepeti tion Factor
LRNC
hSDPACQIFeedbackCy cleK
2 [ms]
Network Services
LRNC
hsDPACQIRepetitionFa ctor
Repetition factor of CQI values. Per default the CQI values are not repeated. In 03.01 only the default selection is supported.
Table 29: HSDPA Physical Layer Parameters

4.3.4.8.1.4 Serving Cell Change Parameters
Parent Object Lcell: HSDPA Lcell: HSDPA Lcell: HSDPA
Parameter Name hSDPASrvCellChgCrit.hyst eresis hSDPASrvCellChgCrit.time To Trigger hSDPASvrCellChgCrit.use CIO
Recommend ed Setting 3 [dB] 640 [ms] TRUE
Range
Short Description Hysteresis value for triggering the change of the best cell within the active set Time to trigger before a event 1D is sent Indicator whether a cell specific offset is used for event 1D evaluation
Lcell
outFDDAdjCells.cellOffset
0 [dB]
-10.0 to 10.0 [dB] (in 0.5 dB steps)
Setting of the cell specific offset
LRNC
srvHSDSCHCellChgCommi tLatencyTime
60 [10 ms]
Reconfiguration time for serving cell change. Node B commits and the UE activates a new transport channel configuration for HS-DSCH serving cell change after that time. The RNC stops scheduling data to the old serving cell this time before the reconfiguration time of the serving cell change. This parameter applies only to InterNode B serving cell change. Guard time for serving cell change procedure
LRNC
minTimeStopSchedSrvHSD SCHCellChg
10 [10ms]
LRNC
srvHSDSCHCellChgeGuard Time
10000 [ms]
Table 30: HSDPA Serving Cell Change Parameters

4.3.4.8.1.5 Mobility Parameters
Parent Object LRNC
Parameter Name hSDPAMobilityThreshold
Recommend ed Setting 1 [seconds]
Range
Short Description A mobility timer tracks the number of serving cell changes. If the timer exceeds a threshold the HS-DSCH is reconfigured to DCH. Upper limit for the mobility timer Hysteresis to switch from PS over HS-DCH to PS over DCH in case of high mobility.
LRNC LRNC
hSDPAMobilityMaxFactor hSDPAMobilityDCHFactor
10 9.9
Network Services
Table 31: HSDPA Mobility Parameters

4.3.4.8.1.6 Call Set Up and State Transition Parameters
Parent Object LRNC
Parameter Name minRateForHSDSCH
Recomme nded Setting 33 [kbps]
Range 0 to 1000 [kbps]
Short Description If the core network requests a data rate below this threshold, the call is automatically set up at DCH Maximal UL data rate at initial RAB establishment At this time the Node B commits and the UE activates the new radio bearer during DCH to HSDSCH radio bearer reconfiguration At this time the Node B commits and the UE activates the new radio bearer during HS-DSCH to DCH radio bearer reconfiguration If this parameter is set to true, the RLC configuration is changed during DCH to HS-DSCH radio bearer reconfiguration Guard time for DCH to HS-DSCH radio bearer reconfiguration Additional guard timer for DCH to HS-DSCH radio bearer reconfiguration Additional guard timer for HSDSCH to DCH radio bearer reconfiguration
LRNC
initialHsdpaUplinkRateRABEst ablish
128 [kbps]
pSDATAR ATE3_64 pSDATAR ATE3_128
LRNC
dCHHSDSCHCommitLatency Timer
65 [10 ms]
LRNC
hSDSCHDCHCommitLatency Timer
65 [10 ms]
LRNC
dCHHSDSCHRLCChange
TRUE
LRNC LRNC
tDCHHSDSCH dCHToHSDSCHReconfigurati onProcedureTimer hSDSCHToDCHReconfigurati onProcedureTimer
3000 [ms] 100000 [ms] 100000 [ms]
LRNC
Table: HSDPA Call Set Up and State Transition Parameters 4.3.4.8.2 Engineering Guideline
Following parameters are organized by function group and in alphabet order for easy reference and described in following fashion: Name of parameters Parameter Name in database: as seen on OMC GUI Access in OMC GUI :navigation path to locate the parameter and how this parameter is accessed (if or not the object has to be blocked) Unit & Range Granularity: network element levels this parameter can be accessed (RNC, Cell level, etc.) Description: Dependencies and constraints: is this parameter correlated to other parameters and any constraints on how this parameter value should be set.
Network Services
Setting Tradeoff: impact when the value is set to high and low values. Engineering Recommendation: Cingulars choice on parameter value based on latest strategy and/or field study. AccessRules RW RO ROSC RWLO RWPL RWEL RWDC Access Interface RNCCLI OMC The parameter is read-write The parameter is read-only The parameter is writable at creation then it is read-only The parameter is read-write only when the object is locked The parameter is read-write only when parent object is locked The parameter is read-write only when top-level object is locked DC = Direct Connect (parameters are adjustable via LMT, only). LMT = Local Maintenance Terminal
MostoftheseparametersareRNCCLIaccessibleonly.Fortheseparameters,thegeneral recommendationisnottochangethemfromCingulardefaultuntilfurthernoticefromHQ.It isbelievedthatsuchparametershavebeenoptimizedusingadvancedsimulationandwork wellinnormaltrafficconditions. Furthermonitoringofnetworkperformanceandtrialswillberuntostudytheseparameters. Notificationwillbeissuedtotheaudienceofthisfieldguideforanyupdatedvalue. ThissectionisintendedtoprovideguidanceonOMCaccessibleparametersandRNCCLI parameterthataremostrelevanttonetworkperformanceandcustomerexperience.Forallthe otherlesscriticalRNCCLIaccessibleonlyparameters,refertoparameterexcelsheetin section7.1,thisfieldguideandLucentLoadControlTAN. ItisstronglyrecommendednottomodifytheCLIonlyparametersasthesearesensitive parameterswithhighimpactonperformance.ForOMCaccessibleparameters,current recommendationsshouldbefollowedandalternationshouldbecoordinatedbyHQand Regionalleads. HSDPAConfigurationParameters
Hsdpacapable
Parameter Name in database: cellResource.hsdpaCapable Access in OMC GUI: LCell HSDPA tab. OMC-RO Unit & Range: True/False. Granularity: per Cell Description: indicates if the cell supports HSDPA
Network Services
Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: True
HsdpaActivation
Parameter Name in database: hSDPAActivation Access in OMC GUI: LRNC HSDPA tab. OMC-RW Unit & Range: True/False. Granularity: per RNC Description: indicates if the RNC supports HSDPA Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: True
HSCCHCode
Parameter Name in database: hSSCHcode Access in OMC GUI: LCell HSDPA tab. OMC-RW Unit & Range: Sequence Length: {1,...,4} Values: {0,...,127}. Granularity: per Cell Description: The parameter hSCCHcode sets both the number of HS-SCCH channels per cell as well as the number of channelization codes to be used for HS-SCCH within the code tree. See section 4.3.4.4.1. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: {3,8,9,10} this should not be changed as to maximize the orthogonality.
HSDPAMeasurementOffset
Parameter Name in database: hSDPAMeasurementPowerOffset Access in OMC GUI: CLI only, LRNC CLI RW Unit & Range: {-6, -5.5,,13} dB in step of 0.5 Granularity: per RNC Description: The measurement power offset is signaled by the RNC and the reference power adjustment is given for each UE category. See section 4.3.4.5.3 for more details. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 6 dB
HSDPAResourceAllocationScheme
Parameter Name in database: hsdpaResourceAllocationScheme Access in OMC GUI: NodeB OMC RW LO Unit & Range: SmallModel = 0 LargeModel = 1 Granularity: per NodeB Description: it allows choosing the Node B configuration. The configuration of the Node B impacts the setting of the number of codes being available for HS-PDSCH. In 03.01 and initial Cingular deployment, only small mode is used. See section 4.3.4.3.1 and 4.3.4.3.4. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 0 (small model) this is the current Cingular deployment option.
HSDPAStartCode
Network Services
Parameter Name in database: hSDSCHStartCode Access in OMC GUI: LCell HSDPA tab OMC RW Unit & Range: {1,., 12} Granularity: per Cell Description: The parameter hSDSCHStartCode states the number of the first channelization code of SF = 16 used for HSDPA. Dependencies and constraints: The sum of hSDSCHStartCode + numberOfHSDSCHcode must be less or equal to 16 since only 16 SF = 16 codes are available. See section 4.3.4.4.1. Setting Tradeoff: Engineering Recommendation: 12
HSPDSCHandHSCCHTotalPower
Parameter Name in database: hSPDSCHSCCHpower Access in OMC GUI: LCell HSDPA tab OMC RW Unit & Range: {0, 0.1, ,50} dBm in step 0.1 Granularity: per Cell Description: maximal power to be allowed for all codes used for HS-PDSCH and HS-SCCH. Dependencies and constraints: Setting Tradeoff: in 03.01, since HSDPA power is also included in the DL load estimation, this parameter should not be set to too high value which could block DCH call setup. In 03.03 this behavior will be changed. See section 4.3.4.4.2. Engineering Recommendation: 42
InitialHSDPAUplinkRateRABEstablishment
Parameter Name in database: initialHsdpaUplinkRateRABEstablish Access in OMC GUI: LRNC radioresource tab OMC RW Unit & Range: 64 kbps or 128 kbps Granularity: per RNC Description: set the uplink rate at initial RAB establishment for HSDPA call. See section 4.3.4.6.1. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 128 kbps
MaximumNumberofHSDPAUsersPerCell
Parameter Name in database: maxHsdpaUsersPerCell Access in OMC GUI: LCell HSDPA tab OMC RW Unit & Range: {032} Granularity: per Cell Description: During call set up, HS-DSCH serving cell change and transition from URA_PCH/ CELL_FACH to CELL_DCH with HSDPA the number of active HSDPA users is checked on a cell base against the parameter maxHsdpaUsersPerCell, since the HSDPA hardware and processing resources are limited in the Node B. See section 4.3.4.3.1 and 4.3.4.6.1. Dependencies and constraints: if small model is chosen as HSDPA Resource Allocation Scheme, value 8 should be used. In either small or large model case, 24 is the upper limit. Setting Tradeoff: Engineering Recommendation: 8
NumberofHSDSCHCodes
Parameter Name in database: numberOfHSDSCHcode Access in OMC GUI: LCell HSDPA tab OMC RW Unit & Range: {1,...,12} Granularity: per cell
Network Services
Description: sets the number of HS-PDSCH codes. See section 4.3.4.4.1. Dependencies and constraints: The sum of hSDSCHStartCode + numberOfHSDSCHcode must be less or equal to 16 since only 16 SF = 16 codes are available. Setting Tradeoff: Engineering Recommendation: 4
MAChsParameters HSDPAACk/NACKRepetitionFactor
Parameter Name in database: hSDPAACKNACKRepetitionFactor Access in OMC GUI: CLI only: RNC CLI RO Unit & Range: {1,...,4} Granularity: per RNC Description: define the repetition factor for ack/nack report. See section 4.3.4.5.3. Dependencies and constraints: only value 1 is supported in 03.01. Setting Tradeoff: Engineering Recommendation: 1
HSDPACQIFeedbackCycle
Parameter Name in database: hSDPACQIFeedbackCycleK Access in OMC GUI: CLI only: RNC CLI RO Unit & Range: {0, 2, 4, 8, 10, 20, 40, 80, 160 ms} Granularity: per RNC Description: define the Feedback cycle of CQI values. See section 4.3.4.5.3. Dependencies and constraints: only value 2 ms is supported in 03.01. Setting Tradeoff: Engineering Recommendation: 2 ms
HSDPACQIRepetitionFactor
Parameter Name in database: hSDPACQIRepetitionFactor Access in OMC GUI: CLI only: RNC CLI RO Unit & Range: {1,...,4} Granularity: per RNC Description: define the repetition factor for CQI report. See section 4.3.4.5.3. Dependencies and constraints: only value 1 is supported in 03.01. Setting Tradeoff: Engineering Recommendation: 1
HSDPAdiscardTimer
Parameter Name in database: hSDPADiscardTimer Access in OMC GUI: LRNC HSDPA tab OMC RW Unit & Range: {0, 20.200 in step of 20 ms; 250, 300, 400, 500, 750, 1000, 1250, 1500, 1750, 2000, 2500, 3000, 3500, 4000, 4500, 5000, 7500 ms} Granularity: per RNC Description: In order to control the dwell time of a MAC-d PDU in the priority queue a discard timer is introduced defining the time to live from the instant of its arrival into a priority queue. After expiration of the timer the MAC-d PDU is discarded. Value 0 means that no discarding is allowed. See section 4.3.4.5.3. Priority queuing and HARQ handling. Dependencies and constraints:
Network Services
Setting Tradeoff: This value should not be set too small to prevent unnecessary RLC retransmission. It should not be set to 0 (disable discarding) as this may lead to data call drops in bad RF condition, caused by Unrecoverable RLC errors. Engineering Recommendation: 2000 ms. With this setting, RLC retransmissions and control PDUs are not excessively queued, with the result that RLC retransmissions and control PDUs have a chance to get through before the described timeout mechanism kick in - even during a sustained throughput drop. This allows the UE-RLC transmit window to advance, or the RLC reset procedure to terminate. Unrecoverable RLC error is avoided. After recovery of lower layer throughput, RLC can continue quickly with retransmissions (if any required) and speed up again.
HSDPAMacHsWindowSize
Parameter Name in database: hSDPAMacHsWindowSize Access in OMC GUI: LRNC Hsdpa tab OMC RW Unit & Range: {4,6,8,12,14,16,24,32} Granularity: per RNC Description: The UE monitors the difference between the sequence numbers of already correctly received MAC-hs PDUs and the sequence numbers of those MAC-hs PDUs that are still outstanding. See section 4.3.4.5.3. Priority queuing and HARQ handling. Priority queuing and HARQ handling. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 32
HSDPAT1Timer
Parameter Name in database: hSDPAT1 Access in OMC GUI: LRNC Hsdpa tab OMC RW Unit & Range: {10,100 in step of 10 ms; 120, 140, 160, 200, 300, 400 ms} Granularity: per RNC Description: The timer T1 is started for an outstanding MAC-hs PDU as soon as MAC-hs PDUs with higher sequence number are correctly received in the reordering unit. See section 4.3.4.5.3. Priority queuing and HARQ handling. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 200 ms
Network Services
Physical Layer Parameters HSDPAACKPowerOffset
Parameter Name in database: hSDPAACKpowerOffset Access in OMC GUI: CLI accessible only. LCell CLI RW Unit & Range: {0, 1,. 8} Granularity: per Cell Description: it is used to decide the power offset between DPCCH and HS DPCCH when HS DPCCH carries ACK message. See section 4.3.4.5.3. (6). Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 6 (meaning HS DPCCH s power is 2 dB higher than DPCCH)
HSDPACPQPowerOffset
Parameter Name in database: hSDPACQIpowerOffset Access in OMC GUI: CLI accessible only. LCell CLI RW Unit & Range: {0, 1,. 8} Granularity: per Cell Description: it is used to decide the power offset between DPCCH and HS DPCCH when HS DPCCH carries CQI report. See section 4.3.4.5.3. (6). Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 6 (meaning HS DPCCH s power is 2 dB higher than DPCCH)
HSDPANACKPowerOffset
Parameter Name in database: hSDPANACKpowerOffset Access in OMC GUI: CLI accessible only. LCell CLI RW Unit & Range: {0, 1,. 8} Granularity: per Cell Description: it is used to decide the power offset between DPCCH and HS DPCCH when HS DPCCH carries NACK message. See section 4.3.4.5.3. (6). Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 6 (meaning HS DPCCH s power is 2 dB higher than DPCCH)
HSDPA Serving Cell Change Parameters HSDPAServingCellChangeHysteresis
Parameter Name in database: hSDPASrvCellChgCrit.hysteresis Access in OMC GUI: LCell hsdpa tab OMC RW Unit & Range: {0, 0.5,, 7.5} db in step of 0.5 Granularity: per Cell Description: Hysteresis value for triggering the change of the best cell within the active set. See section 4.3.4.7.1. Dependencies and constraints: Setting Tradeoff: If set to large value, HSDPA serving cell change will be delayed. Engineering Recommendation: 3 dB
Network Services
HSDPAServingCellChangeTimeToTrigger
Parameter Name in database: hSDPASrvCellChgCrit.timeToTrigger. Access in OMC GUI: LCell hsdpa tab OMC RW Unit & Range: {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640,1280, 2560, 5000 ms} Granularity: per Cell Description: Time to trigger before a event 1D is sent See section 4.3.4.7.1. Dependencies and constraints: Setting Tradeoff: If set to large value, HSDPA serving cell change will be delayed. Engineering Recommendation: 640 ms
HSDPAServingCellChangeCIO
Parameter Name in database: outFDDAdjCells.cellOffset. Access in OMC GUI: LCell adjacentCell tab OMC RW Unit & Range: {-10, -9.5 10 dB in step of 0.5} Granularity: per adjacent Cell Description: Setting of the cell specific offset. Same as CIO used in SHO and IRAT HO. See section 4.3.4.7.1. Dependencies and constraints: Setting Tradeoff: Certain neighbors can be given higher priority than others if CIO is used and CIO is positive for these cells. Engineering Recommendation: 0 dB (no differentiation among all neighbors)
HSDPAServingCellChangeUseCIO
Parameter Name in database: hSDPASrvCellChgCrit.useCIO. Access in OMC GUI: LCell hsdpa tab OMC RW Unit & Range: TRUE/FALSE Granularity: per Cell Description: if set to TRUE, adjacent Cell CIO will be used to weight adjacent cell. See section 4.3.4.7.1. Dependencies and constraints: Setting Tradeoff:. Engineering Recommendation: TRUE
MinimumTimetoStopScheduleDatatoServingCellduringCellChange
Parameter Name in database: minTimeStopSchedSrvHSDSCHCellChg Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0, 255} unit 10ms. Granularity: per RNC Description: The RNC stops scheduling data to the old serving cell this time before the reconfiguration time of the serving cell change. This parameter applies only to Inter Node B serving cell change. See section 4.3.4.7.1. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 10 (meaning 10 * 10ms = 100 ms)
ServingCellChangeCommitTime
Parameter Name in database: srvHSDSCHCellChgCommitLatencyTime Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0, 255} unit 10ms. Granularity: per RNC
Network Services
Description: Reconfiguration time for serving cell change. Node B commits and the UE activates a new transport channel configuration for HS-DSCH serving cell change after that time. See section 4.3.4.7.1. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 60 (meaning 60 * 10ms = 600 ms)
ServingCellChangeGuardTime
Parameter Name in database: srvHSDSCHCellChgeGuardTime Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0, 65535} unit ms. Granularity: per RNC Description: Guard time for serving cell change procedure. See section 4.3.4.7.1. Dependencies and constraints: This timer must be greater than srvHSDSCHCellChgCommitLatencyTime plus some time for the NBAP radio link reconfiguration procedure and the receipt of the RRC message TRANSPORT CHANNEL RECONFIGURATION COMPLETE. Setting Tradeoff: Engineering Recommendation: 10000 ms
Mobility Parameters HSDPAMobilityDCHFactor
Parameter Name in database: hSDPAMobilityDCHFactor Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0, 0.1,, 10} in step of 0.1 Granularity: per RNC Description: Hysteresis to switch from PS over HS-DCH to PS over DCH in case of high mobility. See section 4.3.4.7.3. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 1
HSDPAMobilityMaximumFactor
Parameter Name in database: hSDPAMobilityMaxFactor Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0, 0.1,, 10} in step of 0.1 Granularity: per RNC Description: Upper limit for the mobility timer. See section 4.3.4.7.3. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 10
HSDPAMobilityMaximumFactor
Parameter Name in database: hSDPAMobilityMaxFactor Access in OMC GUI: LRNCl HSDPA tab OMC RW Unit & Range: { 1,,,255 seconds in step of 1} Granularity: per RNC Description: A mobility timer tracks the number of serving cell changes. If the timer exceeds a threshold the HS-DSCH is reconfigured to DCH. See section 4.3.4.7.3. Dependencies and constraints: The timer hSDPAMobilityTimer is upper limited to the product of the configurable parameters hSDPAMobilityThreshold * hSDPAMobilityMaxFactor.
Network Services
Setting Tradeoff: Engineering Recommendation: 9.9 seconds
State Transition Parameters MinimumDLRateforHSDSCH
Parameter Name in database: minRateForHSDSCH Access in OMC GUI: LRNC raidoresource tab. OMC RW Unit & Range: {0, 1000} unit Kbps. Granularity: per RNC Description: If the core network requests a data rate below this threshold the call is automatically set up at DCH. See section 4.3.4.6.1 Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 33 Kbps
DCHtoHSDSCHChangeCommitLatencyTimer
Parameter Name in database: dCHHSDSCHCommitLatencyTimer Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0,...,255} unit 10 ms. Granularity: per RNC Description: At a time derived using this parameter the Node B commits and the UE activates the new radio bearer during DCH to HS-DSCH radio bearer reconfiguration. See section 4.3.4.6.2 Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 65 (i.e. 650 ms)
DCHtoHSDSCHReconfigurationProcedureTimer
Parameter Name in database: dCHToHSDSCHReconfigurationProcedureTimer Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0,,2147483647} unit ms. Granularity: per RNC Description: Additional guard timer for DCH to HS-DSCH radio bearer reconfiguration. See section 4.3.4.6.2 Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 10000 ms
HSDSCHtoDCHChangeCommitLatencyTimer
Parameter Name in database: hSDSCHDCHCommitLatencyTimer Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0,...,255} unit 10 ms. Granularity: per RNC Description: At a time derived using this parameter the Node B commits and the UE activates the new radio bearer during HSDSCH to DCH radio bearer reconfiguration. See section 4.3.4.6.2 Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 65 (i.e. 650 ms)
HSDSCHtoDCHReconfigurationProcedureTimer
Parameter Name in database: hSDSCHToDCHReconfigurationProcedureTimer

Network Services
Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0,,2147483647} unit ms. Granularity: per RNC Description: Additional guard timer for HSDSCH to DCH radio bearer reconfiguration. See section 4.3.4.6.2 Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 10000 ms
DCHHSDSCHtransitiontimer
Parameter Name in database: tDCHHSDSCH Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0, 100,...,5000} unit ms. Granularity: per RNC Description: Guard time for HS-DSCH <--> DCH radio bearer reconfiguration, if it expires before transition is completed (Radio Bearer Reconfiguration Complete message received by RNC), the PS bearer will be released. See section 4.3.4.6.2 Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 3000 ms
Network Services
4.3.5
4.3.5.1
Inter-Technology Handovers (IRAT)

Cingular Strategy
IRAT HO will typically occur at network boundaries where the contiguous UTRAN coverage ends but it can also occur inside the contiguous UTRAN network in areas of poor coverage such as in-building. The strategy should be to keep the UE on the UTRAN frequency for as long as the link quality is good before initiating an IRAT HO. It is prudent to not wait till the link has severely degraded before initiating an IRAT setup as it takes some time for the IRAT HO to be setup which might result in a call drop. Inter-RAT handover/CCO with Compressed Mode (CM) is recommended because it allows the UE to measure the candidate neighbor cells and thereby increase handover success rates and performance. CM allows the Inter-RAT handover to be deployed under various RF conditions, including the non-1:1 UMTS-GSM overlay configuration. CM also improves the retainability rate after the call is handed over to GSM because the best GSM neighbor cell based on available information is chosen, rather than just the underlay GSM cell in Blind Mode, which may not be the best candidate cell to hand down to. It is also important to note that since CM come in expense of increased radio interference in both downlink and uplink, the system capacity will be degraded. This is mainly caused by power rise due to Power Control mechanism during CM. Therefore, one of strategic goals is to also minimize the time UEs spend in CM. In another word, enter CM as soon as needed and execute IRAT HO as quick as quality allowed.
4.3.5.2
Overview
Lucent's handover decision algorithm allows flexible implementations for voice traffic routing from UMTS to GSM. It includes two algorithms, the database-assisted handover algorithm and the mobileassisted handover algorithm, which can be activated alternatively or simultaneously in a cell. This offers network operators the possibility to choose the optimum solution according to local circumstances. Database-Assisted Handover (DAHO) does not require any measurements of the GSM frequencies. The handover decision is based on UE measurements of the used UMTS frequency and configuration data. Therefore it has no negative impact on the radio capacity, which would be the case, if UEs require compressed mode for measuring the GSM signals. This is suitable for the case where a UMTS cell is totally inside coverage of one (1) GSM cell. Mobile-Assisted Handover (MAHO) relies on UE measurements of GSM neighbor cells. The handover decision is based on UE measurements of the used UMTS frequency and the GSM frequencies, which may result in a capacity degradation (higher power due to power control in CM thanks to SF/2 method), if UEs are requiring compressed mode (CM) for inter-RAT measurements. The DAHO and MAHO algorithms can be enabled separately or simultaneously in a cell. The system selects the algorithm autonomously based on configuration data and UE capabilities. Priority is given to MAHO, if both algorithms are applicable at the same time. In current Cingulars network, conditions to meet DAHO requirement is of low probability so it is not recommended to use DAHO for IRAT HO in wide scope. (Simply not defining any DAHO adjacent cell will disable this function). Therefore, in this release, this document will only explain MAHO and MAHO related parameters. For more details on DAHO, refer to Customer_UMTS_RF_TAN_U03.01_InterRAT_Handover_UMTS-GSM (note: there might be some interim compromising solutions for HSDPA related IRAT HO coming in late 03.01 load that might utilize DAHO for HSDPA PS calls. Related information will be provided in later release of this document when that occurs).
Network Services
The handover decision algorithm detects up to three potential GSM target cells, which are used for successive handover attempts. If handover procedure has failed for all suitable GSM target cells (e.g., because of blocking in the GSM network), the handover decision algorithm is invoked again. Note that successive handover attempts are not executed if the handover fails because the UE is not able to establish the call in the GSM system due to insufficient radio conditions. Inter-system handover is always a hard handover with MSC involvement. Upon an inter-system handover trigger UTRAN initiates the Relocation Preparation Procedure at the Iu interface towards the MSC. The UE must have established at least a circuit switched (CS) connection to the UMTS network. Inter RATHandover can be performed for the following RAB combinations: One CS voice connection or One CS voice connection and simultaneous PS connection. For a UE, which is involved simultaneously in a CS connection and a PS connection, the CS connection will be transferred to the target GSM cell first. When the CS handover is completed, the UE has to perform Routing Area Update to continue PS session and PS session will continue if 2G SGSN accept it and the PDP context is still active (PDP timeout timer not expires). Upon a handover failure the CS and PS connections are further served by the UMTS network if possible according to the radio conditions. For PS only connection, Cell Change Order (CCO) procedure will be used instead for PS session in Cell_DCH state and UE controlled Cell reselection will be used for PS session only in CELL_FACH, CELL_PCH, URA_PCH or in case of radio link failure (if UE can not return to UMTS). In current 03.01 release, Lucent does not support CCO. So a PS only traffic will eventually go to Cell FACH mode and perform IRAT cell reselection to 2G which will take 40-60 seconds. In later release (03.02 onward), CCO will be supported. For more details, see 3GPP TS25.133 Requirements for support of radio resource management. 4.3.5.3 Basic Algorithm
The RNC starts a measurement control cycle with events 2D and 2F (starts with communicating e2d/e2f parameters in measurement control message) if all of the following conditions are satisfied: A radio link has been set up/added. At least one cell in the active set has an adjacent GSM cell. A CS RAB is established The UE supports a handover to GSM. (note: in Lucent, there are some more restraints that may affect the RNC decision to send e2d/e2f parameters in measurement control messages. One of them is a MSC parameter for service based HO (shall not, should not, should): if Should or shall not are used, CM will not be started. Another is that if CM is disabled by parameter compressedModeInterRat in LCell object. For more on service HO, see Lucent IRAT TAN.) The RNC figures out if the UE supports intersystem handover according to the RRC CONNECTION SETUP COMPLETE message received from the UE at the communication start.
Network Services
The UE reports event 2D to the RNC via a MEASUREMENT REPORT message if the CPICH measurement result of the currently used frequency falls below the e2d threshold (umts2GsmQActCM2D.threshold) for period of time defined by parameter umts2GsmQActCM2D.timetotrigger since the UE moves to the system border. On reception of event 2D, the RNC sends the conditions for event 3A to the UE (in measurement control) and starts, depending on the UEs capabilities, compressed mode for intersystem handover. Compressed mode is not required if the UE features a second receiver channel. During compressed mode, the UE monitors the GSM adjacent cell based on these conditions. RNC will first demand NodeB to get ready (NBAP message Radio link reconfiguration prepare), once that happens, RNC will then notify UE through Radio Bearer Reconfiguration message to provide CM parameters to UE; UE will respond with Radio Bearer Reconfiguration Complete to indicate its ready; at this stage, UE is configured but CM is still inactive. Then RNC will send measurement control message to demand UE to activate the CM. While the UE is in compressed mode, the RNC updates the list of GSM neighbor and the requested measurements stored in the UE every time the active set is updated. When a radio link is added while the UE is in compressed mode, the configuration activation parameters are provided for the new radio link. There are two ways to activate CM: SF/2 (reduce spreading factor by factor of 2) or HLS (higher layer scheduling). In current 03.01 release, only SF/2 is supported. HLS will be supported in later release (03.02 for UL for certain RAB and 04.01 for DL RAB). The UE reports event 3A to the RNC via MEASUREMENT REPORT message if the CPICH measurement result of the currently used frequency falls below the e3a threshold (umts2GsmQTriggerMAHO.threshold) and that of the other system (GSM) exceeds the threshold (umts2GsmHOMeas.gsmQualityThreshold) for period of time defined by parameter umts2GsmQTriggerMAHO.timetotrigger. Afterward, the RNC triggers intersystem handover and CM will be deactivated. If event 2F is received before event 3A, compressed mode is deactivated and the UE remains in UTRAN. 2F is reported if the CPICH measurement result of the currently used frequency exceeds the threshold (umts2GsmQDeactCM2F.threshold) for period of time defined by parameter umts2GsmQDeactCM2F.timetotrigger. The RAB is released and events 3A and 2D are deactivated if the cells in the active set do not have adjacent GSM cells any longer due to any of the following reasons: A cell of the active set is deleted A cell of the active set is replaced due to a soft handover during event report waiting period Figure 87 illustrates these steps involved in IRAT HO.
Network Services
Figure 87. Inter System HO
Network Services
Measurement Quality UMTS

Measurement Quality GSM
QUsed TUsed 2 f + H 2 f / 2 QUsed TUsed H 3a / 2

MR 2f MR 2d MR 2d MR 3a
QUsed TUsed 2 d H 2 d / 2
CPICH#1
M GSM TGSM + H 3a / 2
E2f threshold E3a GSM threshold E2d threshold
E3a UMTS treshold
Time
Time to trigger TTT

UMTS No CM UMTS CM
TTT
UMTS No CM
TTT
UMTS CM GSM
Figure 88. parameters involved in IRAT HO Figure 88 also depicts the relations of the parameters involved in IRAT HO. These formula and parameters are further discussed in following sections. Threshold This parameter is used to define the radio quality (CPICH Ec/Io) in the network. Hysteresis Generally, hysteresis is used to limit the amount of event-triggered reports and its connected to the threshold for a particular event like in the formulas below. In other words with this parameter its possible to prevent unnecessary reporting due to the regular signal fluctuations. Measurement reporting activation (2D) Triggering condition - needed to trigger an event.
Used
T Used
2 d
2 d
/ 2
Qused: current measurement of CPICH Ec/Io (RSCP will be supported in future release) defined below:
QUTRAN = 10 LogM UTRAN

QUTRAN MUTRAN Mi NA MBest W
NA = W 10 Log M i + (1 W ) 10 LogM Best i =1
is the estimated quality of the active set on the used frequency is the estimated quality of the active set on the used frequency is a measurement result of cell i in the active set the used frequency is the number of cells in the active set on the used frequency is the measurement result of the cell in the active set with the highest measurement result is a weighting factor sent from UTRAN to UE (umts2GsmQTriggerMAHO.weight)
(note: high layer filtering can be used to further alleviate the signal fluctuation effect. This is done by introducing coefficient parameters)
Network Services
With weighting factor, user can control the influence of Best active cell in quality measurement results therefore affect the timing of event triggers. For instance, if W is set to 0, only Best Primary CPICH is compared against threshold therefore could trigger e2d event prematurely, especially in pilot polluted areas (no dominant server); if W is set to 1, the overall Quality will be a composite value of all active set cells therefore could delay e2d triggering. H2d: It is broadcast in Measurement Control message (when System sees one active set cell contains GSM neighbours). In Lucent, this is internally calculated value, not directly configurable. Hysteresis 2d = Hysteresis 2f = (e2f threshold e2d threshold) = e2d threshold = umts2GsmQActCM2D.threshold e2f threshold = umts2GsmQDeactCM2F.threshold umts2GsmQActCM2D.threshold and umts2GsmQDeactCM2F.threshold are configurable parameters through OMC GUI. Tused 2d: threshold used by UE for triggering e2d event. It is broadcast in Measurement Control message (when System sees one active set cell contains GSM neighbours). Tused 2d = e2d threshold + Hysteresis / 2 = e2d threshold + (e2f threshold e2d threshold)/2 = (e2d threshold + e2f threshold) / 2 e2d threshold = umts2GsmQActCM2D.threshold e2f threshold = umts2GsmQDeactCM2F.threshold Example: if umts2GsmQActCM2D.threshold = -13 dB and umts2GsmQDeactCM2F.threshold = -11 dB Hyesteresis 2d = Hysteresis 2f = -11 (-13) = 2 dB Tused 2d = -13 dB + 1 = -12 dB So UE will send e2d report when its Ec/Io falls below -12 2/2 = -13 dB. As one can see, effectively, it will be the same as what the OMC GUI parameter is set for. (note: in Lucent, Tused 2f = Tused 2d)
Figure 89. example of e2d/e2f parameters in MC message
Network Services
Leaving triggered state condition - needed to decide, when a new measurement report must be sent, if the triggering condition is fulfilled again (in case of no periodical reporting). Basically, the new measurements report will be sent after the leaving condition has been verified. In case periodical reporting is activated, the event will be send until the leaving condition or the value amount of reporting was reached. For instance, UE sends e2d if the quality follow below Tused Hys/2. As long as the quality remains below Tused + Hys/2, no new e2d event will be sent. If the quality raises above Tused + Hys/2 and after that decreases again below Tused Hys/2, UE will send again a e2d event.
Used
> T Used
2 d
+ H
2 d
/ 2
Figure 90. event 2D triggering Time to Trigger: defined by parameter: umts2GsmQActCM2D.timetotrigger Measurement reporting deactivation (2F) If event 2F is received before event 3A, compressed mode is deactivated and the UE remains in UTRAN. 2F is reported if the CPICH measurement result of the currently used frequency exceeds the threshold umts2GsmQDeactCM2F.threshold. Currently only Ec/No is used. RSCP will be supported in later release. The UE deactivates compressed mode and GSM cell measurements if any of the following conditions is satisfied:
The cells in the active set do not have adjacent GSM cells any longer as a result of a handover in UMTS. The CS RAB and the PS RAB are both released. Only the PS RAB remains and Cell Change Order is not permitted. Event 2F is detected.
Triggering condition
Used
T Used
2 f
+ H
2 f
/ 2
Network Services
Qused: same as used in E2d section. H2f: same as H2d in Lucent system. Tused 2f: threshold used by UE for triggering e2f event. It is broadcast in Measurement Control message (when System sees one active set cell contains GSM neighbours). In Lucent, it is set to be equal to Tused 2d. Effectively, it will be the same as what the OMC GUI parameter (umts2GsmQDeactCM2F.threshold) is set for.
Figure 91. event 2F triggering HO execution (event 3A) Triggering conditions For quality/coverage evaluation of UMTS network:
Used
T Used
3 a
/ 2
TOther + H 3a / 2
For coverage estimation of GSM network:
M Other
RAT
+ CIO Other
RAT
RAT
Qused: same as e2d and e2f case. H3a: in Lucent, it is always set to 0. (no configurable parameter) Tused: threshold used by UE for triggering e3a event. It is broadcast in Measurement Control message (after e2d event is reported). It is set by parameter umts2GsmQTriggerMAHO.threshold. MotherRAT : is the measurement quantity for the cell of the other system (BCCH RSSI in case of GSM) TOtherRAT : is the absolute threshold that applies for the other system in that measurement (in GSM case, BCCH RSSI), aka umts2GsmHOMeas.gsmQualityThreshold in Lucent.
Network Services
CIO: Cell Individual Offset. It is used to give certain GSM neighbor cells priority over others if needed. This can be used to direct traffic towards particular GSM cells for traffic and quality reason. It can be configured through OMC GUI.
Figure 92. event 3A triggering
4.3.5.4 Engineering Guideline for IRAT related parameters

4.3.5.4.1 Summary table
Following is a brief summary table for currently applicable IRAT HO parameters in Lucent. (applicable means that certain parameters such like DAHO related are excluded as DAHO is not being used by Cingular in current network deployment)
parametername
parameternamein database
range
Cingular Default
description
Network Services

The parameter defines whether the use of the compressed mode is allowed in the cell for inter-RAT measurements. If the active set contains a cell for that compressed mode is disabled, then MAHO is possible for UEs not requiring compressed mode, only.
ActivateCMforIRAT
Lcell::Inter SystemHO::compressed ModeInterRat
True/False
TRUE
BorderCelltoGSM
Lcell::borderCellToGsm
True/False
TRUE
BSICVerification
LRNC::GSMextTable::bs icVerificationRequired
True/False
TRUE
combinedgsm neighborlistsize
LRNC::umts2GsmHOM eas.combinedGsmNeigh bourListSize
1..32instep of1
20
Marksacellasabordercellofthe UMTSnetworktoaGSM network. TheBSICVerificationRequired parameterdefineswhether,in caseofMAHO,theUEhasto verifytheBSICoftheGSM frequencyinordertorecognize theGSMcellasvalidfor handover. Thisparameterdefinesthe maximumnumberofGSM neighbourcellsrelatedtothe activeset,whichshouldbe measuredbytheUE Theparameterenables/disables theGSMtoUMTShandover featureonapercellbasis. Thresholdfor3a(HOexecution) Thehandoverrelocationguard timerdefinestheminimumtime forretriggeringarelocationfora newhandoverattempt,ifthe previoushandoverattemptwas notsuccessful.Thetimeris starteduponinitiationofthe RelocationPreparationProcedure withUEinvolvement(handover). Whenthetimerexpires (handovernotsuccessful),the handoverdecisionfunctionis activatedinordertoallowthere triggerofnewhandover attempts.
GSMtoUMTS Handover
LRNC::GSMExtTable::gs mToUmtsHandover
True/False
FALSE
gsmQualityThreshold (gsmThresh3a)
LRNC::umts2GsmHOM eas.gsmQualityThreshol d
115...0dBm
98
HandoverRelocation GuardTimer
hoRelocGuardTimer
560seconds instepof1
10
Network Services

coeff_0, coeff_1,., coeff_9, coeff_11, coeff_13, coeff_15, coeff_17, coeff_19
InterRAT filtercoefficient
LRNC::uMTS2GSMHO meas.gsmfiltercoefficien t
coeff_3
Definesalowpassfilterforthe GSMmeasurements.Usedfor measurementsforevent3Aand event3C. LengthoftimethesourceRNC willawaitanIURELEASE COMMANDfromtheSGSN, aftertheRNChasreceivedanIU RELEASECOMMANDfromthe MSCindicatingthatthe Relocationwassuccessful. Thisparameterenables/disables themobileassistedhandover algorithm(MAHO)fortriggering theUMTStoGSMhandover procedure. distinguishnameofthecell Eachservingcellcan enable/disablebroadcastof parametersofitsparticular neighbourcells.True:The particularneighbourcellshallbe broadcastforcellreselection. False:Theparticularneighbour cellshallnotbebroadcastmaybe usedforotherpurposes. DefineswhethertheGSM neighbourcellshouldbeusedas targetforUMTStoGSM handoverwithMAHOalgorithm. LengthoftimethesourceRNC willawaitaresponsefromthe CNaftersendinga RELOCATIONREQUIRED messagetotheCN.Ifthetimer expirestheRNCwillabortthe RelocationPreparationprocedure byinitiatingtheRelocation Cancelprocedure.
iuReleaseCoordinatio nTimer
LRNC:timers1:iuRelease CoordinationTimer
1100 seconds
20
MAHOGSM Measurements
Lcell::mahoByGsmMeas urements
True/False
TRUE
OutGSMAdjCells referencecell
OutGSMAdjCells.refCell
nameofthe neighborcell
perdesign
OutGSMAdjCells enableBroadcast
OutGSMAdjCells.enable Broadcast
True/False
TRUE
OutGSMAdjCells enableMAHO
OutGSMAdjCells.enable MAHO
True/False
TRUE
Relocation PreparationTimer
LRNC:timers1:tRelocPr ep
120seconds
Network Services
TRelocOverall
LRNC:timers1:tRelocOv erAll
120seconds
LengthoftimethesourceRNC willawaitafurtherresponsefrom theCNafterreceivinga RELOCATIONCOMMAND messagefromtheCN.Ifthetimer expirestheRNCwillreleasethe IuconnectionbysendinganIu RELEASEREQUESTmessageto theCN. Theparameterenables/disables theUMTStoGSMhandover featureperRNC Ec/Nothresholdfortriggerevent 2dforCMactivation Specifiesthetimeforwhichthe triggeringconditionmustbetrue beforetheUEsendsanevent triggeredmeasurementreportto theUTRAN
umtstoGsm handover umts2GsmQActCM2 D.threshold (usedFreqThresh2dEc no)
LRNC::umtsToGsmHan dover
True/False
TRUE
Lcell::umts2GsmQActC M2D.threshold
24...0dB
13
umts2GsmQActCM2 D.timeToTrigger
Lcell::umts2GsmQActC M2D.timetotrigger
0,10,20,40,60,8 0,100,120,160,2 00,240,320,640, 1280,2560,5000 ms
320
umts2GsmQDeactCM 2F.threshold (usedFreqRelThresh2f Ecno)
Lcell::umts2GsmQDeact CM2F.threshold
24...0
11
Ec/Nothresholdfortriggerevent 2fforCMdeactivation Specifiesthetimeforwhichthe triggeringconditionmustbetrue beforetheUEsendsanevent triggeredmeasurementreportto theUTRAN
umts2GsmQDeactCM 2F.timeToTrigger
Lcell::umts2GsmQDeact CM2F.timetotrigger
0,10,20,40,60,8 0,100,120,160,2 00,240,320,640, 1280,2560,5000 ms
640
umts2GsmQTriggerM AHO.threshold (utranThresh3aEcno)
Lcell::umts2GsmQTrigg erMAHO.threshold
24...0dB
13
Ec/NothresholdforHOtrigger
umts2GsmQTriggerM AHO.timeToTrigger
Lcell::umts2GsmQTrigg erMAHO.timetotrigger
0,10,20,40,60,8 0,100,120,160,2 00,240,320,640, 1280,2560,5000 ms
Specifiesthetimeforwhichthe triggeringconditionmustbetrue beforetheUEsendsanevent triggeredmeasurementreportto theUTRAN. Specifiesweightingbetweenthe strongestlinkandremaining activelinksforcomputingthe qualityoftheUMTSsystem.
Weighting(3a)
LCell::umts2GsmQTrigg erMAHO.weight
0.0upto2.0 stepsize=0.1
Network Services
4.3.5.4.2
Engineering Guideline
Following parameters are organized in alphabet order for easy reference and described in following fashion: Name of parameters Parameter Name in database: as seen on OMC GUI Access in OMC GUI :navigation path to locate the parameter and how this parameter is accessed (if or not the object has to be blocked) Unit & Range Granularity: network element levels this parameter can be accessed (RNC, Cell level, etc.) Description: Dependencies and constraints: is this parameter correlated to other parameters and any constraints on how this parameter value should be set. Setting Tradeoff: impact when the value is set to high and low values. Engineering Recommendation: Cingulars choice on parameter value based on latest strategy and/or field study. ActivateCMforIRAT
Parameter Name in database: compressedModeInterRat Access in OMC GUI: LCell Inter-system handover tab. OMC-RW Unit & Range: True / False Granularity: per Cell Description: The parameter defines whether the use of the compressed mode is allowed in the cell for inter-RAT measurements. If the active set contains a cell for that compressed mode is disabled, then MAHO is possible for UEs not requiring compressed mode, only. Dependencies and constraints: n/a Setting Tradeoff: n/a Engineering Recommendation: True
BorderCelltoGSM
Parameter Name in database: borderCellToGSM Access in OMC GUI: LCell Inter-system handover tab. OMC-RW Unit & Range: True / False Granularity: Cell level Description: Marks a cell as a border cell of the UMTS network to a GSM network. The MAHO algorithm takes the parameter into account for the handover decision. Quality based handover with MAHO algorithm is considered if the active set contains at least one border cell, only. Dependencies and constraints: n/a Setting Tradeoff: n/a Engineering Recommendation: True.
BSICVerification
Parameter Name in database: bsicVerificationRequired Access in OMC GUI: LRNC GSMExtCell table (right click and open) gsm tab. OMC-RW Unit & Range: true/false Granularity: per GSM Ext Cell (i.e. gsm neighbor) Description: The BSIC Verification Required parameter defines whether, in case of MAHO, the UE has to verify the BSIC of the GSM frequency in order to recognize the GSM cell as valid for handover. Dependencies and constraints: n/a Setting Tradeoff: n/a Engineering Recommendation: True.
Network Services
combinedgsmneighborlistsize
Parameter Name in database: combinedGsmNeighbourListSize Access in OMC GUI: LRNC homeasurement tab Umts2GsmHoMeas. OMC-RW Unit & Range: 1..32 in step of 1 Granularity: per RNC. Description: This parameter defines the maximum number of GSM neighbour cells related to the active set, which should be measured by the UE. GSM cell in composite neighbor list for cells in active set will not be measured by UE if such GSM cells are outside of Top N neighbor cell list. N = parameter value. Dependencies and constraints: n/a Setting Tradeoff: If this parameter is set to a too low value then it may happen that the GSM cell with best coverage at the current location of the UE is not in the list and not considered for handover. If no handover target is found and the UMTS quality becomes to low, the call may drop. If this parameter is set to a too high value then the UE may need several compressed mode gaps to determine the best GSM cell. The handover may get delayed by some 100 milliseconds. Engineering Recommendation: 20
GSMtoUMTSHandover
Parameter Name in database: gsmToUmtsHandover Access in OMC GUI: LCell inter-systemHO tab OMC-RW Unit & Range: True/false Granularity: per Cell Description: The parameter enables/disables the GSM to UMTS handover feature on a per cell basis. Dependencies and constraints: n/a Setting Tradeoff: n/a Engineering Recommendation: False (disable GSM to UMTS HO)
GsmQualityThreshold(gsmThresh3a)
Parameter Name in database: gsmQualityThreshold Access in OMC GUI: LRNC homeasurement tab Umts2GsmHoMeas. OMC-RW Unit & Range: -115 ... 0 dBm Granularity: per RNC Description: Threshold for 3a (HO execution). GSM neighbor cell in question must be stronger than this threshold in order for 3a event to be triggered. Dependencies and constraints: n/a Setting Tradeoff: If this parameter is set to a too low value then an inter-RAT handover may get triggered although no GSM cell is available with sufficient coverage. The inter-RAT handover will not succeed. If this parameter is set to a too high value then no inter-RAT handover may get triggered although one or more GSM cells are available with sufficient coverage. If the UMTS quality becomes to low, the call may drop. Engineering Recommendation: -98 dbm.
HandoverRelocationGuardTimer
Parameter Name in database:hoRelocGuardTime Access in OMC GUI: LRNC handover tabl handover table section Unit & Range: 5 60 seconds Granularity: RNC level
OMC_RW
Network Services
Description: The handover relocation guard timer defines the minimum time for retriggering a relocation for a new handover attempt, if the previous handover attempt was not successful. The timer is started upon initiation of the Relocation Preparation Procedure with UE involvement (handover). When the timer expires (handover not successful), the handover decision function is activated in order to allow the re-trigger of new handover attempts. Dependencies and constraints: this parameter value should be greater than parameter TRELOCprep Setting Tradeoff: If this parameter is set to a too low value then the RNC will re-trigger a relocation very soon after the previous failed relocation. The probability is high that the relocation will fail again and so on. Signaling and processing effort is increased. If this parameter is set to a too high value then the RNC will wait a long time before re-triggering the relocation in case that the previous relocation request got lost. If the relocation procedure takes too much time and the radio conditions get worse, the call may drop. Engineering Recommendation: 10 seconds
InterRATfiltercoefficient
Parameter Name in database: gsmfiltercoefficient Access in OMC GUI: LRNC homeasurement tab Umts2GsmHoMeas. OMC-RW Unit & Range: coeff_0, coeff_1, ., coeff_9, coeff_11, coeff_13, coeff_15, coeff_17, coeff_19 Granularity: per RNC Description: Defines a low pass filter for the GSM measurements. Used for measurements for event 3A and event 3C. Information on the filter formula is available in 3GPP TS 25.331 8.6.7.2. Dependencies and constraints: n/a Setting Tradeoff: If this parameter is set to 0 then no filtering is performed, i.e. the latest measured value is used for comparison with the threshold. The last measured value may have a high deviation from the average (or actual) value. If the last measured value was higher than the average and the actual GSM quality is not sufficient then an inter-RAT handover may get triggered but not succeed. If this parameter is set to a high value then the filtering may cause a long delay before changes in the GSM RSSI value have effect on the filtered measurement result. An inter-RAT handover to GSM may get initiated but not succeed because the GSM quality is no longer sufficient. Or no inter-RAT handover to GSM is triggered and the call may drop due to insufficient UMTS quality because it has not been recognized that a GSM cell has become good enough meanwhile. Engineering Recommendation: coeff_3.
IuReleaseCoordinationTimer
Parameter Name in database: iuReleaseCoordinationTimer Access in OMC GUI: LRNC timers1. OMC-RW Unit & Range: 1 100 seconds in step of 1 Granularity: per RNC Description: Length of time the source RNC will await an IU RELEASE COMMAND from the SGSN, after the RNC has received an IU RELEASE COMMAND from the MSC indicating that the Relocation was successful. Dependencies and constraints: The timer must be high enough to allow establishment of the UE in the new cell and a subsequent SRNS context transfer procedure. Setting Tradeoff: If this parameter is set to a too low value then the RNC would initiate the release of the Iu connection to the SGSN before the SRNS context forwarding procedure could be executed in case that the packet session should be continued in the GSM system. If this parameter is set to a too low value then the RNC would initiate the release of the Iu connection to the SGSN before the SRNS context forwarding procedure could be executed in case that the packet session should be continued in the GSM system. Engineering Recommendation: 20 seconds
Network Services
MAHOGSMMeasurements
Parameter Name in database: mahoByGsmMeasurements Access in OMC GUI: LCell inter-systemHO tab OMC-RW Unit & Range: true/false Granularity: per Cell Description: This parameter enables/disables the mobile-assisted handover algorithm (MAHO) for triggering the UMTS to GSM handover procedure Dependencies and constraints: n/a Setting Tradeoff: n/a Engineering Recommendation: True (enable)
OutGSMAdjCellsreferencecell
Parameter Name in database: OutGSMAdjCells refcell Access in OMC GUI: LCell adjacentCell tab OutGSMAdjCell table OMC-RW Unit & Range: n/a Granularity: per Cell (per GSM neighbor) Description: distinguish name of the GSM neighbor cell Dependencies and constraints: n/a Setting Tradeoff: n/a Engineering Recommendation: per design
OutGSMAdjCellsenableBroadcast
Parameter Name in database: OutGSMAdjCells.enableBraodcast Access in OMC GUI: LCell adjacentCell tab OutGSMAdjCell table OMC-RW Unit & Range: true/false Granularity: per Cell (per GSM neighbor) Description: Each serving cell can enable/disable broadcast of parameters of its particular neighbour cells. True: The particular neighbour cell shall be broadcast for cell reselection. False: The particular neighbour cell shall not be broadcast may be used for other purposes Dependencies and constraints: n/a Setting Tradeoff: n/a Engineering Recommendation: True (enable)
OutGSMAdjCellsenableMAHO
Parameter Name in database: OutGSMAdjCells.enableMAHO Access in OMC GUI: LCell adjacentCell tab OutGSMAdjCell table OMC-RW Unit & Range: true/false Granularity: per Cell (per GSM neighbor) Description: Defines whether the GSM neighbour cell should be used as target for UMTS to GSM handover with MAHO algorithm. Dependencies and constraints: n/a Setting Tradeoff: n/a Engineering Recommendation: True (use)
RelocationPreparationTimer
Parameter Name in database: tRelocPrep Access in OMC GUI: LRNC timers1 tab. OMC-RW Unit & Range: 1 20 seconds Granularity: per RNC
Network Services
Description: Length of time the source RNC will await a response from the CN after sending a RELOCATION REQUIRED message to the CN. If the timer expires the RNC will abort the Relocation Preparation procedure by initiating the Relocation Cancel procedure Dependencies and constraints: TRELOCprep < hoRelocGuardTimer TRELOCprep must be greater than the relocation allocation guard time in the CN. Setting Tradeoff: If this parameter is set to a too low value then the RNC will cancel the relocation procedure although the relocation request may be still active in the MSC. No relocation can be performed. If this parameter is set to a too high value then the RNC will wait a long time before it cancels the active relocation procedure in case that the relocation request got lost. The time until re-trigger of the relocation (hoRelocGuardTimer) is even longer and if the relocation procedure takes too much time and the radio conditions get worse, the call may drop. Engineering Recommendation: 5 seconds
TRelocOverall
Parameter Name in database: tRelocOverAll Access in OMC GUI: LRNC timers1 tab. OMC-RW Unit & Range: 1 20 seconds Granularity: per RNC Description: Length of time the source RNC will await a further response from the CN after receiving a RELOCATION COMMAND message from the CN. If the timer expires the RNC will release the Iu connection by sending an Iu RELEASE REQUEST message to the CN. Dependencies and constraints: Value must be greater than the relocation complete guard time in the CN (TRELOCcomplete). Setting Tradeoff: If this parameter is set to a too low value then the following can happen: If the handover to GSM fails and the UE wants to return to its UMTS connection, then the RNC may already have requested the Iu release and the UE is not able to continue its call. If this parameter is set to a too low value then the following can happen: If the handover to GSM fails and the UE wants to return to its UMTS connection, then the RNC may already have requested the Iu release and the UE is not able to continue its call. Engineering Recommendation: 5 seconds
umts to Gsm handover

Parameter Name in database: umtsToGsmHandover Access in OMC GUI: LRNC handover tabl handover table section OMC_RW Unit & Range: true / false Granularity: per RNC Description: The parameter enables/disables the UMTS to GSM handover feature per RNC Dependencies and constraints: n/a Setting Tradeoff: n/a Engineering Recommendation: True (allowed)
umts2GsmQActCM2D.threshold
Parameter Name in database: umts2GsmQActCM2D.threshold Access in OMC GUI: LCell Inter-system handover tab umts2GsmQActCM2D section . OMCRW Unit & Range: -24 ... 0 dB Granularity: per Cell Description: Ec/No threshold for trigger event 2d for CM activation. See section 4.3.5.2.2 for more details on how this parameter is used to calculate usedFreqThreshold2d broadcast in measurement control message.
Network Services
Dependencies and constraints: umts2GsmQActCM2D.threshold < umts2GsmQDeactCM2F.threshold umts2GsmQActCM2D.threshold >= umts2GsmQTriggerMAHO.threshold umts2GsmQDeactCM2F.threshold - umts2GsmQActCM2D.threshold <= 14 Setting Tradeoff: If this parameter is set to a too low value then the compressed mode is activated too late. The call may drop before inter-RAT measurements can be performed and the handover to GSM is initiated. The parameter can be set to the same or higher value than the handover threshold (umts2GsmQTriggerMAHO.threshold). The time during that compressed mode is active is reduced to a minimum if both thresholds are set to the same value. However, a higher threshold for compressed mode activation may be required to regard for further quality degradation during the time that is needed by the UE to perform the inter-RAT measurements. If this parameter is set to a too high value then the compressed mode is activated earlier than required. Compressed mode is active although the quality of the UMTS signal is sufficient and interRAT handover needs not to be considered at this time. Compressed mode has negative impact on the throughput and/or cell capacity and it should be avoided to activate compressed mode if it is not required. Engineering Recommendation: -13 dB
umts2GsmQActCM2D.timeToTrigger
Parameter Name in database: umts2GsmQActCM2D.timeToTrigger Access in OMC GUI: LCell Inter-system handover tab umts2GsmQActCM2D section . OMCRW Unit & Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 ms Granularity: per Cell Description: Specifies the time for which the triggering condition must be true before the UE sends an event triggered measurement report to the UTRAN Dependencies and constraints: Setting Tradeoff: If this parameter is set to a too low value then the measurement report is sent even if the trigger condition is only fulfilledfor a very short time. Such fast time fading may be caused for example by interference and should not cause the activation of compressed mode. If this parameter is set to a too high value then the compressed mode may get activated too late. In case of bad quality the UE has to wait for the time to trigger before sending the measurement report. Further time is required to activate compressed mode, take the inter-RAT measurements and execute the handover to GSM. During this time the UE may have already moved out of coverage of the UMTS area and the call may drop. Engineering Recommendation: 320 ms
umts2GsmQDeactCM2F.threshold
Parameter Name in database: umts2GsmQDeactCM2F.threshold Access in OMC GUI: LCell Inter-system handover tab umts2GsmQDeactCM2F section . OMCRW Unit & Range: -24 ... 0 dB Granularity: per Cell Description: Ec/No threshold for trigger event 2f for CM deactivation, See section 4.3.5.2.2 for more details on how this parameter is used to calculate usedFreqThreshold2f broadcast in measurement control message. Dependencies and constraints: see parameter umts2GsmQActCM2D.threshold Setting Tradeoff: If this parameter is set to a too low value then the compressed mode is deactivated after a previous activation if the UMTS quality raises only by a small amount. This can cause a frequent toggling of the compressed mode that causes high signalling and may have negative effect on the call quality.
Network Services
If this parameter is set to a too high value then the compressed mode is kept activated very long. Compressed mode is active although the quality of the UMTS signal is sufficient again and inter-RAT handover needs not to be considered at this time. Compressed mode has negative impact on the throughput and/or cell capacity and it should be avoided to keep compressed mode active when not required. Engineering Recommendation: -11 dB
umts2GsmQDeactCM2F.timeToTrigger
Parameter Name in database: umts2GsmQDeactCM2F.timeToTrigger Access in OMC GUI: LCell Inter-system handover tab umts2GsmQDeactCM2F section . OMCRW Unit & Range: 0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 ms Granularity: per Cell Description: Specifies the time for which the triggering condition must be true before the UE sends an event triggered measurement report to the UTRAN Dependencies and constraints: n/a Setting Tradeoff: If this parameter is set to a too low value then the measurement report is sent even if the trigger condition is only fulfilled for a very short time. Such fast time fading should not cause the deactivation of compressed mode. If this parameter is set to a too high value then the compressed mode may get deactivated very late. Engineering Recommendation: 640 ms
umts2GsmQTriggerMAHO.threshold(e3athreshold)
Parameter Name in database: umts2GsmQTriggerMAHO.threshold Access in OMC GUI: LCell Inter-system handover tab umts2GsmQTriggerMAHOsection. OMC-RW Unit & Range: 24...0dB Granularity: per Cell Description: Specifies a value for the quality of the own system (UMTS frequency) for triggering inter-RAT MAHO in case of Service Handover set to "should not" (actual quality drops below specified threshold) Dependencies and constraints: umts2GsmQActCM2D.threshold >= umts2GsmQTriggerMAHO.threshold Setting Tradeoff: If this parameter is set to a too low value then the handover is triggered too late. I.e. the call quality may get unacceptably bad or the call may even drop. The value should be chosen higher than required for minimal call quality of a static call. This is necessary to regard for the time that is required to execute the handover to GSM and the movement of the UE. If this parameter is set to a too high value then the handover is triggered too early. A handover to GSM is performed although the quality of the UMTS signal is sufficient, i.e. the UE is still inside the UMTS area. Engineering Recommendation: -13 dB (same as e2D threshold) so UE can trigger HO immediately at least one GSM neighbor meets requirement.
umts2GsmQTriggerMAHO.timeToTrigger(e3atimetotrigger)
Parameter Name in database: umts2GsmQTriggerMAHO.timeToTrigger Access in OMC GUI: LCell Inter-system handover tab umts2GsmQTriggerMAHO section . OMC-RW Unit & Range0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000 ms Granularity: per Cell
Network Services
Description: Specifies the time for which the triggering condition must be true before the UE sends an event 3a triggered measurement report to the UTRAN. Dependencies and constraints: n/a Setting Tradeoff: If this parameter is set to a too low value then the measurement report is sent even if the trigger condition is only fulfilled for a very short time. Such fast time fading may be caused for example by interference and should not cause a handover to GSM. If this parameter is set to a too high value then the handover to GSM may be triggered too late. In case of bad quality the UE has to wait for the time to trigger before sending the measurement report. This time in conjunction with the time for the execution of the handover to GSM, the UE may have already moved out of coverage of the UMTS area and is not able to receive the handover command from the UMTS network. In this case the call will drop. Engineering Recommendation: 0 ms.
Weighting(3a)
Parameter Name in database: umts2GsmQTriggerMAHO.weight Access in OMC GUI: LCell Inter-system handover tab umts2GsmQTriggerMAHO section . OMC-RW Unit & Range: 0.0 up to 2.0 step size=0.1 Granularity: per Cell Description: Specifies weighting between the strongest link and remaining active links for computing the quality of the UMTS system. Dependencies and constraints: n/a Setting Tradeoff: If this parameter is set to a low value then the quality of the strongest cell has higher influence on the estimated quality of the active set. In case of weight=0 the strongest cell is taken into account, only. If this parameter is set to a high value then the quality of the strongest cell has less influence on the estimated quality of the active set. In case of weight=1 all cells of the active set are taken account with same preference. In case of weight>1 the quality of the strongest cell is taken into account with lower preference than the other active set cells. See section 4.3.5.2.2. under description of e2D event for more details on this parameter. Engineering Recommendation: 1 (believed to have better accuracy)
4.3.5.5
2G to 3G HO
See guideline and parameter recommendations on 2g to 3G HO in GSM Field Guide: Nokia GSM IRAT guideline, Ericsson GSM Vol. II FG, Siemens GSM (ND-00126)
Network Services
5. OSS Implementation Guide

This section provides an overview of the implementation activities for the Lucent OSS. It outlines the steps of implementing and testing the OSS release of Lucents Radio Access products for Cingular UMTS markets. The initial Cingular UMTS network will be based on the 3GPP R4+ architecture specifications. It will include all the relevant services in the specifications that are applicable to the Cingular mobile environment. High quality voice services along with data services with high throughput and differential QoS will be supported. The core network will support all the radio access bearers that are also being supported in the UTRAN and the UE with their corresponding QoS requirements. The UMTS core network will support inter-working with GSM core network for handover between UMTS and GSM access for seamless voice service and improved coverage for all services. This will provide capabilities to introduce multimedia services including real time and streaming voice and video services. See the attached Lucent OSS Implementation Guide.
6. OCNS
The purpose of this section is to provide operational procedures for Lucents Orthogonal Channel Noise Simulator (OCNS) for 03.01. OCNS is used to simulate downlink traffic load within a cell or cluster of cells. Lucents Translation Application Note for OCNS can be used to address the sensitivity of input parameters and its effects on the simulated downlink load distribution for voice and data OCNS simulations. The TAN is divided into two main parts: the first part explains the OCNS feature and its translation in detail whereas the second part describes some simulation results and gives examples for specific traffic models. See the Lucent OCNS Translation Application Note for additional details.
Network Services
7. UMTS Recommended Parameters
7.1
Parameters to be Used for Launch and Moderately Loaded Clusters LU-0301-UTRAN-Parameters-v3.3
7.2
Parameters to be Used for Acceptance Testing and High Capacity Clusters

To be added later
Network Services
8. Test Results
This section will contain summaries, and links to the Lab, FOA, SOA, and Parameter specific-testing results.
8.1
8.1.1
FOA Test Results

Executive Summary (FOA)
This section should include a list of all Severity 1 and 2 items Identified during the FOA testing and the associated patches/fixes delivered to resolve the issue: Also a list of unresolved bugs identified
8.1.2
Link to Results (FOA)

Here is the link to the 03.01 FOA Lab results. Here is the link to the 03.01 FOA field results: P0 Test Results and P1 lite Test Results
8.2
8.2.1
Parameter Field Trial Results

Executive Summary (Parameter Field Trial)
This section should include a list of all Severity 1 and 2 items Identified during the SOA testing and the associated patches/fixes delivered to resolve the issue: Also a list of unresolved bugs identified
8.2.2
Link to Results (Parameter Field Trials)

Here are the outputs from various Access, IRAT, and Cell Reselection Parameter Field Trials with Lucent and Qualcomm.
Network Services
9. Implementation Guides
This section will links to various implementation guides available from CTO: Implementation Guides
10. Reference List and Index

10.1 Reference
Lucent 03.01 Translation Application Notes (TAN): Customer_UMTS_RF_TAN_U03.01_Access_Procedures Customer_UMTS_RF_TAN_U03.01_Cell_Selection_Reselection Customer_UMTS_RF_TAN_U03.01_Handover Customer_UMTS_RF_TAN_U03.01_Inter-RAT_Handover_UMTS-GSM Customer_UMTS_RF_TAN_U03.01_HSDPA Customer_UMTS_RF_TAN_U03.01_Load_Control_Algorithms Customer_UMTS_RF_TAN_U03.01_OCNS Customer_UMTS_RF_TAN_U03.01_Power_Control
Introduction to WCDMA: Physical Channels, Logical Channels, Network, and Operation by Lawrence Harte ALTHOS 2004 WCDMA for UMTS: Radio Access For Third Generation Mobile Communication (Third Edition) by Harri Holma and Antti Toskala, Wiley 2004 Radio Network Planning and Optimization for UMTS, by J. Laiho, A. Wacker, T Novosad, Wiley 2004 25.101-680: User Equipment (UE) radio transmission and reception (FDD) (Rel. 6) 25.213-550: Spreading and Modulation (Rel 5) 25.214-5a0: Physical Layer procedure (Rel. 5) 25.215-630: Physical layer Measurement (FDD) (Rel. 6) 25.304-570: UE Procedure in Idle Mode and Cell reselection in connected mode, Rel. 5. 25.321-5a0: MAC layer protocol and specification (Rel 5) 25.331-5b0: RRC layer protocols (Rel. 5)
Network Services
10.2 Index
To be added later.
Network Services
11. Appendix
11.1 Appendix A Compressed Mode Description
During compressed mode, the UE periodically creates transmission gaps (idle time) by compressing the information to be transmitted, see figure below. The system reduces the spreading factor by 2 to temporarily accelerate the transmission rate. Thus, it can maintain the bit rate of the normal transmission by using only the slots excluding the transmission gap. Since the spreading gain decreases during the compressed transmission due to the increase of the bit rate, the transmission power rises temporarily to keep the quality. Higher transmission power increases the interference, which results in decreasing the radio capacity.
Compressed mode for intersystem and interfrequency measurements can be activated independently for uplink or downlink transmission or for both directions. Compressed mode patterns for intersystem and interfrequency measurements cannot be active at the same time. The interaction between interfrequency measurements for coverage, adjacent channel interference (ACI) and intersystem measurements are configurable via 2D-event thresholds specified by the e2d parameter. The first 2D event received decides which compressed mode pattern should be activated; any subsequent 2D event received is ignored as long as the compressed mode is activated. Interfrequency and intersystem measurements are stopped if the quality of the current frequency is above a certain threshold. Trigger 2F is used to stop the interfrequency measurements and 2F to stop the intersystem measurements in order to allow a preference against interfrequency handover or intersystem handover. Compressed mode pattern A compressed mode pattern consists of one or two transmission gaps within a certain number of frames. While the UE is in compressed mode, it applies the same pattern for an infinite duration. The pattern type is selected based on the cells of the active set. Compressed mode pattern are defined by 3GPP TR 25.922 and TS25.133. For each measurement purpose, one compressed mode pattern sequence is defined. The pattern sequence is the same for all cells of the RNC.
Network Services
Each compressed mode pattern sequence is associated to exactly one measurement purpose. For GSM measurements, the following measurement purposes exist:
GSM RSSI measurement

The UE starts Received Signal Strength Indicator (RSSI) measurement of the adjacent GSM cell to update the adjacent GSM cell list upon detection of event 2D followed by activation of compressed mode.
Initial BSIC identification

The UE detects SCH and FCH of the GSM cell to measure the timing between the GSM cell and the UMTS cell. After synchronising with the GSM cell, the UE decodes the BCCH of the GSM cell to identify the Base transceiver Station Identity Code (BSIC).
BSIC reconfirmation
The UE reports the occurrence of event 3A to the RNC if the conditions for event 3A are still satisfied after completing the initial BSIC identification. After reporting it, the UE continues to measure the RSSI to reconfirm the BSIC. If the reconfirmation operation fails twice or the reconfirmation cannot be made for a specified period of time, the UE starts the Initial BSIC identification again. Whether or not the BSIC reconfirmation is required after reporting event 3A is specified by the parameter bsicVerificationRequired. Event-triggered measurement reporting is only possible after the UE has confirmed the BSIC. Therefore, BSIC identification and reconfirmation are always required. The RSSI measurement is required to receive a list of GSM cells. The compressed mode pattern for interfrequency measurements does not overlap patterns for intersystem measurements. The parameters to determine these compressed mode patterns are specified by office data and can not be configured by the operator. Code allocation The Node B supports the alternative scrambling code method which is used to select the scrambling code in compressed mode. Each scrambling code is associated with a left alternative scrambling code and a right alternative scrambling code that can be used for compressed frames. The RRC and NBAP protocols provide an indicator to signal that the alternative scrambling code method is used. The code ID itself is not signaled because the Node B and the UE can determine the correct compressed-frame code from the normal scrambling code. The left and right alternative trees are only used for compressed frames. Upon radio interface reconfiguration on dedicated channels and while the downlink compressed mode is active, the UE is informed of the usage of the alternative scrambling code on the new configuration. The RNC uses the measurement control procedure to provide the UE with:
A list of required measurements The GSM neighbor cell information

The UE attempts to find the GSM cells specified in the neighbor cell list and to synchronize with them. Afterward, it provides the required measurement reports. The reporting can be event-triggered or periodic. For more details on CM, refer to chapter 6 in Customer_UMTS_RF_TAN_U03.01_InterRAT_Handover_UMTS-GSM

3G Umts Utran

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

3G Umts Utran

Caricato da

Copyright:

Formati disponibili

Lucent UMTS Field Guide Volume II Feature Parameters and Best Practices

Network Operations Document NetOps-ND-00167

Rev. 1.3 06/07/06

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 1 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 2 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

4.1.4 Paging in Idle Mode .......................................................................................................... 46

4.2.3 Call Establishment ............................................................................................................ 78

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 3 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

4.3.2 Power Control ................................................................................................................. 134

4.3.4 HSDPA............................................................................................................................ 188

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 4 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

10. Reference List and Index ............................................................................................................. 245

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 5 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 6 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 7 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 8 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

Page Left Blank Intentionally

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 9 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

Document Revision History

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 10 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

NetOps-xxxxxND-00167 Rev. 1.3 06/07/06

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Page 11 of 248 (c) 2006 Cingular Wireless

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

1. About This Document

Volume III: Equipment Engineering &

Planning & Standards

Ayman Mostafa Mike Heubel

CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY Use pursuant to Company instructions

Volume II Lucent UMTS Field Guide for UTRAN P-1 Lite

RAN Field Guide Title Hardware Configurations

Team Accountability Field Support