3G UMTS UTRAN

NetOps-xxxxxND-00167 CINGULAR WIRELESS CONFIDENTIAL & PROPRIETARY of 248 Rev. 1.3 06/07/06 Use pursuant to Company instructions (c) 2006 Cingular Wireless

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.

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



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 UMTS Cell Search Procedure........................................................................... 27 4.1.1.2 Planning for Good Network Acquisition Performance....................................... 30

4.1.2 PLMN Selection ................................................................................................................ 31 4.1.3 Cell Selection & Reselection............................................................................................. 31

4.1.3.1 System Information Broadcast (SIB) Parameters for Cell Selection and Reselection ....................................................................................................... 32

4.1.3.2 Cell Selection (i.e. Camping on a Suitable Cell) ............................................... 34 4.1.3.3 Location Area / Routing Area Update ............................................................... 36 4.1.3.4 Cell Reselection ................................................................................................ 37

4.1.4 Paging in Idle Mode .......................................................................................................... 46 4.1.4.1 Discontinuous Reception for Paging................................................................. 46 4.1.4.2 Paging Channel Selection................................................................................. 47 4.1.4.3 Paging Procedures............................................................................................ 48 4.1.4.4 Paging Parameters in Idle Mode....................................................................... 48

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 Phase 1: RACH Preamble Part........................................................................ 54 4.2.2.2 Phase 2: Power Ramping Cycle ...................................................................... 58 4.2.2.3 Phase 3: RACH Message Part ........................................................................ 65 4.2.2.4 RACH Overload Control.................................................................................... 71 4.2.2.5 RACH Overload Control Parameter Settings.................................................... 72 4.2.2.6 Retransmission of the RACH Message Part..................................................... 73 4.2.2.7 Access-related Performance Measurements.................................................... 77

4.2.3 Call Establishment ............................................................................................................ 78 4.2.3.1 Circuit-Switched (CS) Mobile Origination/Termination ..................................... 78 4.2.3.2 Packet-Switched (PS) Mobile Origination/Termination..................................... 92

4.3 Mobility and Connection Management...................................................................................... 97 4.3.1 Load Control ..................................................................................................................... 97

4.3.1.1 Cingular Strategy .............................................................................................. 97 4.3.1.2 Overview ........................................................................................................... 97



4.3.1.3 Load Estimation ................................................................................................ 98 4.3.1.4 Call Admission Control (CAC)......................................................................... 102 4.3.1.5 Congestion Control (CongC)........................................................................... 103 4.3.1.6 Dynamic Bearer Control (DBC)....................................................................... 104 4.3.1.7 RACH Overload Control.................................................................................. 110 4.3.1.8 Aggregate Overload Control ........................................................................... 111 4.3.1.9 Engineering Guidelines for Load Control related parameters......................... 111

4.3.2 Power Control ................................................................................................................. 134 4.3.2.1 Cingular Strategy ............................................................................................ 134 4.3.2.2 Overview ......................................................................................................... 134 4.3.2.3 DPCCH and DPDCH Overview....................................................................... 135 4.3.2.4 Open Loop Power Control............................................................................... 136 4.3.2.5 UL Open Loop Power Control ......................................................................... 137 4.3.2.6 DL Open Loop Power Control (DL DPCH Initial Tx Power)............................ 138 4.3.2.7 DL Closed Loop Power Control ...................................................................... 140 4.3.2.8 UL Closed Loop Power Control ...................................................................... 142 4.3.2.9 DL Power Balancing........................................................................................ 146 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 Cingular Strategy ............................................................................................ 171 4.3.3.2 Overview ......................................................................................................... 171 4.3.3.3 Measurement Control and Reporting.............................................................. 173 4.3.3.4 SHO Algorithm ................................................................................................ 176 4.3.3.5 NLSA (Neighbor List Selection Algorithm) ...................................................... 178 4.3.3.6 Engineering Guidelines ................................................................................... 179

4.3.4 HSDPA............................................................................................................................ 188 4.3.4.1 Cingular Strategy ............................................................................................ 188 4.3.4.2 Overview ......................................................................................................... 188 4.3.4.3 NodeB Capabilities and Configuration ............................................................ 194 4.3.4.4 Code and Power Allocation............................................................................. 196 4.3.4.5 Radio Resource Management ........................................................................ 197 4.3.4.6 State Transition with HSDPA .......................................................................... 202 4.3.4.7 Mobility ............................................................................................................ 204 4.3.4.8 Engineering Guidelines for HSDPA Related UTRAN Parameters.................. 208



4.3.5 Inter-Technology Handovers (IRAT)............................................................................... 222 4.3.5.1 Cingular Strategy ............................................................................................ 222 4.3.5.2 Overview ......................................................................................................... 222 4.3.5.3 Basic Algorithm ............................................................................................... 223 4.3.5.4 Engineering Guideline for IRAT related parameters....................................... 230 4.3.5.5 2G to 3G HO ................................................................................................... 241

5. OSS Implementation Guide ......................................................................................................... 242 6. OCNS........................................................................................................................................... 242 7. 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. Reference List and Index ............................................................................................................. 245

10.1 Reference................................................................................................................................ 245 10.2 Index........................................................................................................................................ 246

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



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



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



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



Page Left Blank Intentionally



Document Revision History This table identifies content revisions made to this document.

Date Rev Revision Description Writer Sponsor

10/15/2005 0.1 Initial Draft J. Derrick Smith Mike Heubel

11/2005 0.4 Added sections up to Section 4.1 (Idle Mode Behavior) J. Derrick Smith Mike Heubel

12/19/05 0.9 Document completion for review J. Derrick Smith Mike Heubel

01/05/06 1.0 Initial Release J. Derrick Smith Mike Heubel

03/14/06 1.0.1 IRAT section added Hendry Tong M. Heubel

06/02/06 1.2 Great details added to Load Control, Power Control, SHO, HSDPA sections. Reformat.

Hendry Tong M. Heubel

06/7/06 1.3 Minor format change; minor parameter ranges change. Official release. Correction in HSDPA section based on comments from Stefan in Lucent.

Hendry Tong M. Heubel

RACI This table identifies RACI team members.

Accountable Responsible Consulted Informed

Mike Heubel J. Derrick Smith

Hendry Tong

Market Engineering

Regional Engineering

National Field Support

HQ Strategic Planning

Lucent Technical Support

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



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 Volume II – Lucent UMTS Field Guide for UTRAN P-1 Lite


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

Description Team Accountability

Responsible Person(s)

Volume I : RF Design Guidelines

UTRAN design principles, guidelines, tools, and techniques. Includes AFP, ACP, Planning Tools, Propagation Tools, Drive Test and Post Processing Equipment/Software Packages.

Planning & Standards

Mark Reudink

Ayman Mostafa

Volume III: Equipment Engineering &

Guidelines for use of ancillary equipment (MCPA, Triplexer, Antenna, TMA,


Ayman Mostafa

Mike Heubel



RAN Field Guide Title

Description Team Accountability

Responsible Person(s)

Hardware Configurations

etc.), Node B specifications and configurations. Internal link budget and FOA/lab test results. Vendor-specific information.

Field Support Greg Scharosch

Volume IV: Optimization Solutions & Techniques

UMTS optimization best practices, parameter trial results, and reports. Optimization tools and techniques. Vendor specific


Field Support

Kaushik Gohel

Ayman Mostafa

Mike Heubel

Greg Scharosch

Volume V : Node-B Voice and Data Dimensioning

Guidelines and assumptions for dimensioning, forecasting, & provisioning.

Business Planning

Field Support

Rick Fish

Mike Heubel

Greg Scharosch

Volume VI: Key Performance Indicators (KPI)

UTRAN Level 1, 2, & 3 counters and KPI descriptions.


Field Support

Kaushik Gohel

Mike Heubel

Greg Scharosch

Volume VII: Capital Planning Guidelines

CES guidelines and capital planning process

Business Planning


Michael Filley

Mark Reudink

Volume VIII: RF Regulatory Mandates & Spectrum Planning

E911, Spectrum Planning, Interference mitigation, RF Exposure

Business Planning

Scott Burke

Volume IX: Business Process

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.



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: [email protected]

Hendry Tong, National RF Field Support – Lucent UMTS, HQ RF Network Operations

Desk: 404-236-5836

Wireless: 404-983-5437

E-mail: [email protected]

mailto:[email protected]

mailto:[email protected]



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 KPI’s



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 UL Frequencies DL Frequencies TX-RX Separation I 1920 - 1980 MHz 2110 - 2170 MHz 190 MHz II 1850 - 1910 MHz 1930 - 1990 MHz 80 MHz III 1710 - 1785 MHz 1805 - 1880 MHz 95 MHz IV 1710 - 1755 MHz 2110 - 2155 MHz 400 MHz V 824 - 849 MHz 869 - 894 MHz 45 MHz VI 830 - 840 MHz 875 - 885 MHz 45 MHz VII 2500 - 2570 MHz 2620 - 2690 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).



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) UE transmit, Node B receive

DOWNLINK (DL) UE receive, Node B transmit

UARFCN Carrier frequency [MHz] (FUL)) (Note 1)

UARFCN Carrier frequency [MHz] (FDL)) (Note 2)

Nu = 5 * FUL 0.0 MHz ≤ FUL ≤ 3276.6 MHz Nd = 5 * FDL 0.0 MHz ≤ FDL ≤ 3276.6

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 UPLINK (UL) UE transmit, Node B receive

DOWNLINK (DL) UE receive, Node B transmit

UARFCN Carrier frequency [MHz] (FUL))

UARFCN Carrier frequency [MHz] (FDL))

II

Nu = 5 * (FUL – 1850.1 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

Nd = 5 * (FDL – 1850.1 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

V Nu = 5 * (FUL – 670.1 MHz)

826.5, 827.5, 831.5, 832.5, 837.5, 842.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

UL Center Frequency (MHz)

DL UARFCN

DL Center Frequency (MHz)

PCS / Cellular Band

12 1852.5 412 1932.5 PCS - A 37 1857.5 437 1937.5 PCS - A 62 1862.5 462 1942.5 PCS - A 87 1867.5 487 1947.5 PCS-D 112 1872.5 512 1952.5 PCS-B 137 1877.5 537 1957.5 PCS-B 162 1882.5 562 1962.5 PCS-B 187 1887.5 587 1967.5 PCS-E 212 1892.5 612 1972.5 PCS-F 237 1897.5 637 1977.5 PCS-C3 262 1902.5 662 1982.5 PCS-C4 287 1907.5 687 1987.5 PCS-C5



782 826.5 1007 871.5 Cellular - A 787 827.5 1012 872.5 Cellular - A 807 831.5 1032 876.5 Cellular - A 812 832.5 1037 877.5 Cellular - A 837 837.5 1062 882.5 Cellular - B 862 842.5 1087 887.5 Cellular - B

Table 4: UTRA Absolute Radio Frequency Channel Number

3.2 UE Transmit power

3.2.1 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.

Power Class 1 Power Class 2 Power Class 3 Power Class 4 Operating Band Power

(dBm) Tol (dB)

Power (dBm)

Tol (dB)

Power (dBm)

Tol (dB)

Power (dBm)

Tol (dB)

Band II +33 - +27 - +24 +1/-3 +21 +2/-2 Band V +33 - +27 - +24 +1/-3 +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

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. Cingular’s 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.

Operating Band Unit DPCH_Ec <REFSENS> <REFÎor> II dBm/3.84 MHz -115 -104.7 IV dBm/3.84 MHz -117 -106.7

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



HS-DSCH category

Maximum number of HS-DSCH

codes received

Minimum inter-TTI interval

Modulation Scheme

Supported

Max # of bits of an HS-DSCH

transport block received within an

HS-DSCH TTI

Total number of

soft channel bits

Maximum Transfer Speed

Supported

Category 1 5 3 QPSK / 16-QAM 7298 19200 1.2 Mbps Category 2 5 3 QPSK / 16-QAM 7298 28800 1.2 Mbps Category 3 5 2 QPSK / 16-QAM 7298 28800 1.8 Mbps Category 4 5 2 QPSK / 16-QAM 7298 38400 1.8 Mbps Category 5 5 1 QPSK / 16-QAM 7298 57600 3.6 Mbps Category 6 5 1 QPSK / 16-QAM 7298 67200 3.6 Mbps Category 7 10 1 QPSK / 16-QAM 14411 115200 7.2 Mbps Category 8 10 1 QPSK / 16-QAM 14411 134400 7.2 Mbps Category 9 15 1 QPSK / 16-QAM 20251 172800 10.1 Mbps Category 10 15 1 QPSK / 16-QAM 27952 172800 14.0 Mbps Category 11 5 2 QPSK only 3630 14400 0.9 Mbps Category 12 5 1 QPSK only 3630 28800 1.8 Mbps

Table 7: UE Categories

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.)



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

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

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:

• 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

Io: • 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

IP

RW

WI

RP

NE rx

rx

o

b o==

Nothown

rx

o

b

PIIP

RW

NE

++−••=

)1( α



⎟⎟⎠

⎞⎜⎜⎝

⎛⋅−⎟⎟

⎠

⎞⎜⎜⎝

⎛⋅−

⎟⎟⎟⎟⎟⎟

⎠

⎞

⎜⎜⎜⎜⎜⎜

⎝

⎛

⎟⎟⎠

⎞

⎜⎜⎝

⎛⋅⎟⎟

⎠

⎞⎜⎜⎝

⎛+

⋅−=DPDCH

DPCCH

DPDCH

userDCHDPCCHUL

actualDCH SF

SFdc

dcN

SIRNo

Eb

R

R log10log20log102

,

ββ

ββ

• 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 [dB]

You can see such usage in many drive test tool measurement report.

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:

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.



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)



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.

Figure 1: UMTS Link Budget Considerations and Interactions

Maximum Acceptable Uplink Pathloss

User Equipment Node B

UE – Antenna losses

Body lossAntennaRX SensitivityRX Noise FigurePenetration Losses

UE – Antenna losses

Body lossAntennaRX SensitivityRX Noise FigurePenetration Losses

Node B – Antenna losses

Node B RX Noise FigureRX Noise DensityRX Noise PowerPenetration LossesInterference MarginCable, connector, and combiner lossesThermal noise densityFast-fading margin

Node B – Antenna losses

Node B RX Noise FigureRX Noise DensityRX Noise PowerPenetration LossesInterference MarginCable, connector, and combiner lossesThermal noise densityFast-fading margin

EIRP

Transmitted Power

UE – GainsAntenna

Receiver Sensitivity

Required Eb/No

Node B – GainsAntennaHandover

User Equipment Node B

Required Eb/No

UE – GainsAntenna

Node B – GainsAntennaHandover

Receiver Sensitivity EIRP

Loading Factor

Environment Correction Reliability Margin

Uplink Pathloss

Output Power per Link

UPLINK BUDGET

DOWNLINK BUDGET



Table 8: Sample Link Budget

unit

UMTS CS

12.2 UMTS PS 64

UMTS PS 128

UMTS PS 384

Formula Descriptions

Carrier Frequency MHz 1900 1900 1900 1900 a Channel Bandwidth MHz 3.84 3.84 3.84 3.84 b No = kT (k = 1.38x10-23 / T = 290 K) dBm/Hz -174.0 -174.0 -174.0 -174.0 c = 10*LOG10(1.38E-23*290*1000)Noise Bandwidth (B) dBHz 65.84 65.84 65.84 65.84 d = 10*LOG10(b * 1000000) Noise in Channel Bandwidth (No * NF * B)

-104.63

-104.63

-104.63

-104.63 e = c + d + h

Mobile Station EIRP dBm 24 24 24 24 f CPICH Power dBm 36 36 36 36 g Node B Noise Figure (NF) dBm 3.5 3.5 3.5 3.5 h Node B Antenna Gain dBi 18 18 18 18 i Node B Transmit Cable Loss dB 3 3 3 3 j Node B Combiner Loss dB 0 0 0 0 k Node B Antenna Slant Loss dB 1.5 1.5 1.5 1.5 l Node B Receive Cable Loss dB 3 3 3 3 m CPICH EIRP dBm 49.5 49.5 49.5 49.5 n = g + i - j - l Node B Antenna Height m 20 20 20 20 o Data rate kbps 12.2 64 128 384 p

Processing Gain dB 24.98 17.78 14.77 10.00q = 10*LOG10((b*1000000)/(p*1000))

Target Eb/No dB 7 5 4.5 3 r

Receiver Sensitivity dBm -

122.61-

117.42-

114.91-

111.63 s = e - q + r Load Factor % 50% 50% 50% 50% t Interference Margin dB 3.0 3.0 3.0 3.0 u = 10*LOG10(1/(1-t)) Maximum Allowable Path Loss dB 160.11 154.92 152.41 149.13 v = f + i - l - m Body Loss Margin dB 3.00 3.00 3.00 3.00 m1 Building/Vehicle Penetration Margin dB 10.00 10.00 10.00 10.00 m2 Shadowing Standard Deviation dB 8.00 8.00 8.00 8.00 Given Cell Area Reliability Target % 0.95 0.95 0.95 0.95 Given Cell Edge Reliability Target % 0.91 0.91 0.91 0.91 Calculated using Reudnik curves Shadowing Margin dB 10.70 10.70 10.70 10.70 m3 Handover Gain/Loss dB 4.10 4.10 4.10 4.10 m4 Total Required Link Margin dB 19.60 19.60 19.60 19.60 m5 = m1 + m2 + m3 - m4 Maximum Cell Range dB 140.51 135.32 132.81 129.53 MCR = v - m5



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



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.

http://ns.cingular.net/RF_ENG/Lucent Documents/Forms/AllItems.aspx?RootFolder=%2fRF%5fENG%2fLucent%20Documents%2fLucent%20UMTS%20Field%20Guide%2fField%20Guide%20Reference%20Documentation&View=%7bEABB106E%2d12CB%2d4913%2dABE1%2d68A3539736E8%7d



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

Parameter Name

Recommended Setting Range Short Description

LCell pCPICHPower

36 dBm (40 W PA) 33 dBm (20 W PA)

10% of Total PA Power

-10 to +50 [dBm]

0.1 dB steps

Total power allocated to the primary common pilot channel (CPICH) in dBm. Important for the 3rd stage of cell search.

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

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).

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

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).

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 cell’s 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



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



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.



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.



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 -95 dBm. (FDD only)

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 Lucent’s 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.



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.

Initial Cell Selection

go here whenever a new PLMN is

selected

1no cell information

stored for the PLMN cell information

stored for the PLMN

Stored information

Cell Selection no suitable cell found

no suitable cell found

Cell Selection when leaving

connected mode

suitable cell found 2

suitable cell found Camped

normally

suitable cell found

no suitable cell found

leave idle mode

return to idle mode

Connected mode Cell

Reselection Evaluation Process

suitable cell found

trigger

Any Cell Selection

go here when no USIM in the UEno suitable

cell found

NAS indicates that registration on selected

PLMN is rejected (except with cause #14

or #15 [5][16])



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 doesn’t 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









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) (dB)




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 Parameter Range Recommendation Description

Cell selection and reselection quality measure cellSelAndResQualMeas CPICH Ec/No,

CPICH RSCP cPICHECNO

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.

Qqualmin sIB3QQualMin* -24 to 0 -19 dB Ec/No [dB]

Qrxlevmin sIB3QRXLevMin* -115 to -25 , 2 dBm steps -115 dBm RSCP [dBm]

Maximum allowed UL TX Power

sIB3MaxAllowed ULTxPower*

-50 to 33, 1 dBm steps 24 dBm Maximum UE Transmit Power

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 cell’s 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.



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.



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



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 intra-frequency 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]

Nserv [number of

DRX cycles]

TmeasureFDD [s] (number of DRX cycles)

TevaluateFDD [s] (number of DRX

cycles)

TmeasureGSM [s] (number of DRX

cycles)

0.08 4 0.64 (8 DRX

cycles) 2.56 (32 DRX

cycles) 2.56 (32 DRX

cycles) 0.16 4 0.64 (4) 2.56 (16) 2.56 (16) 0.32 4 1.28 (4) 5.12 (16) 5.12 (16) 0.64 4 1.28 (2) 5.12 (8) 5.12 (8) 1.28 2 1.28 (1) 6.4 (5) 6.4 (5) 2.56 2 2.56 (1) 7.68 (3) 7.68 (3) 5.12 1 5.12 (1) 10.24 (2) 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).



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



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



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.


sIB3/SIB4Indicator sIB3EnableSIB4Indicator TRUE, FALSE FALSE

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.





SIntraSearch sIB3SIntraSearch* -32 - 20

[dB] 2 dB steps

10 dB

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.

SInterSearch sIB3SInterSearch* -32 - 20

[dB] 2 dB steps

TBD

This parameter defines a threshold for the quality value Squal above which the UE should stop performing inter-frequency FDD measurement. Recommended value of 0 dB will cause the UE to perform inter-frequency measurements only when the current cell is not fulfilling the selection criterion.

sSearchRAT sIB3RAT.sSearchRAT* -32 - 20

[dB] 2 dB steps

4 dB

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 inter-RAT measurements only when the current cell has an Ec/No value lower than -15 dB (sSearchRAT + sIB3QQualMin).

Qhyst1s sIB3Qhyst1* 0 - 40 [dB] 2 dB steps 2 dB

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.

Qhyst2s sIB3Qhyst2* 0 - 40 [dB] 2 dB steps 2 dB

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.

Treselection siB3Treselection* 0 - 31 [sec] 1 sec step 1 sec

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.




Qoffset2s,n

outFDDAdjCells.cellOffset (UMTS) outGSMAdjCells.Qoffset (GSM)

-10 - 10 [dB] UMTS

-50 - 50 [dB] GSM

0 dB (UMTS) 0 dB (GSM)

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.

Qsearch_I 0 - 15 [Integer] 7

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.

FDD_Qmin 0 - 7 [Integer] 7

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.

FDD_Qoffset 0 - 15 [Integer] 0

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.

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



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 cell’s 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.



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.).



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.



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 S-CCPCH 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,



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.




CN DRX Cycle Length Coefficient

cnCsDrxCoefficient cnPsDrxCoefficient

3 to 9 (2^value * 10 ms) 7 (1.28 s)

Periodicity of the paging occasion corresponding to a given UE in idle mode

UTRAN DRX Cycle Length Coefficient uTRANDRXCycleCoefficient 3 to 9

(2^value * 10 ms) 6 (0.64 s)

Periodicity of the paging occasion corresponding to a given UE in connected mode (CELL_PCH and URA_PCH mode)

PICH Power Offset pICHPower -10 to 5 [dB] -6 dB

Power level of the Paging Indicator Channel. This power is set a a relative power in relation to the P-CPICH

Number of PI per frame (Np)

pICHMode 18, 36, 72, 144 18

The maximum number of paging indicators that are transmitted in each Paging Indicator Channel (PICH) frame.

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 call-setup 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.



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)



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



transferred between the UE and the UTRAN. The idle mode processes have been described in the previous section but let’s 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.



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 Lucent’s 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



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.



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 Sub-Channel 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.



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.



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


PRACH preambleSignature 1111111111111111 [65535]

0 to 65535 [Integer]

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.

PRACH subChannelNumbers 111111111111 [4095]

0 to 4095 [Integer]

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.

PRACH constantVal -27 dB -35 to -10 [dB]

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



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 Lucent’s 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 preamble’s 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:



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



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-to-acknowledgement, 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.



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.



Figure 25: Flow Chart for RACH Procedures

Start

Get RACH TX control Parameters from RRC

Any Data to TX on RACH?

ASC Selection (PRACH

probability Pi)

Initialize preamble TX counter M=0

M <= Mmax?

Update RACH TX control parameters

Persistency Delay = 10 ms

Draw Random Number

0<=R<=1

R <= Pi?

Physical Layer Preamble Power Ramping Cycle

Received Acknowledgement ACK?

TX RACH Message Part

Wait for Expiry of Persistency Delay



Set Back-off timer to NB01*10ms where

NB01min <=NB01 <=NB01max

Increment Preamble TX Counter M

Wait for Expiry of Backoff timer

Indicate to higher layer Mmax

reached (TX status “unsuccessful”)

End

No

Yes

No

No

No

Yes

Yes

Yes

Yes

No (NACK)

Case 2 Case 3

Case 4

Case 1

RRC Layer Persistency Check




The parameters associated with this Phase of the Random Access Procedure are presented in the table below.



PRACH PowerRampStep 2 dB 1 - 8 [dB]

UE transmit power increase between subsequent transmissions on the RACH when no acquisition indicator is received

PRACH maxRetranPreamble 15 1 to 64 Maximum number of preamble transmissions in one preamble ramping cycle

LCell sIB3MaxAllowedULTxPower 24 dBm -35 to -10 [dB]

This parameter defined the maximum UE TX power (based upon the power class supported by the network).

PRACH aICHTransmissionTiming att-0 att-0, att-1

This parameter is used by the UE to determine the preamble-to-acknowledgement, preamble-to-message, and minimum preamble-to-preamble distance.

PRACH mMax 3 1 to 32 This parameter defines the maximum number of preamble ramping cycles.

PRACH nB01min 0 ms 0 - 50 ms 10 ms steps

Minimum random back-off time in case of receipt of a negative acknowledgement (NACK) on the AICH.

PRACH nB01max 50 ms 0 - 50 ms 10 ms steps

Maximum random back-off time in case of receipt of a negative acknowledgement (NACK) on the AICH.

PRACH physicalRACHPreambleThreshold -23 dB -36.0 – 0 dB 0.5 dB steps

This threshold is used by the NodeB as a minimum threshold for detecting RACH preambles.

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



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



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 preamble-to-message distance, the UE sends the RACH Message Part. In Lucent’s 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.



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 one-to-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




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 Lucent’s 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.



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

Chosen TFI (TB Size)

RACH Slot Format k / SF to be used

TFCI indicated on Physical Layer

10 ms 1 (232 bits) 2 / 64 1 20 ms 1 (232 bits) 1 / 128 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



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:



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

Quantized Amplitude

ratios βc and βd 15 1.0 14 14/15 13 13/15 12 12/15 11 11/15 10 10/15 9 9/15 8 8/15 7 7/15 6 6/15 5 5/15 4 4/15 3 3/15 2 2/15 1 1/15 0 0/15

Table 16: Quantization of Gain Factors βc and βd


The parameters associated with this Phase of the Random Access Procedure are presented in the table below.





TFC GainFactorBc 7 (7/15) 1 - 15 Used by the UE as the gain factor for the control part of the RACH Message Part (DPCCH)

TFC GainFactorBd 15 (1.0) 1 - 15 Used by the UE as the gain factor for the data part of the RACH Message Part (DPDCH)

TFC PowerOffsetPpm 0 dB -5 to +10 [dB]

Used by the UE to calculate the power offset between the power of the acknowledged preamble and the power of the DPCCH.

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. Lucent’s 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:



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

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 Lucent’s 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.

pd

o

preamblec

o

messageb GN

EN

E+⎟⎟

⎠

⎞⎜⎜⎝

⎛+++= 2

c

2

m-p,, 1log10POffset Power

ββ

Margintion Implementa 1log10POffset Power 2c

2,,

m-p +−⎟⎟⎠

⎞⎜⎜⎝

⎛+−−= p

d

o

preamblec

o

messageb GN

EN

Eββ



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.



Parent Object

Parameter Name


LCell persistLow 6 1 to 8

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.

LCell persistHigh 2 1 to 8

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.

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.



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.



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.



LRNC t300 t300_1200

100, 200, 400, 600, 800, 1000,

1200, 1400, 1600, 1800, 2000, 3000, 4000, 6000, 8000 [ms]

UE guard timer that is supervising the RRCConnectionSetup procedure when the UE is waiting for the RRCConnectionSetup message.

LRNC n300 3 0 to 7 [Integer]

Defines the number of times that the UE is allowed to send the same RRC Connection Request message

LRNC t302 t302_4000

100, 200, 400, 600, 800, 1000,

1200, 1400, 1600, 1800, 2000, 3000, 4000, 6000, 8000 [ms]

UE guard timer that is supervising the Cell/URA Update procedure when the UE is waiting for the CellUpdateConfirm/URAUpdateConfirm message





LRNC n302 2 0 to 7 [Integer]

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



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 Lucent’s 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.



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 Circuit-Switched (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:



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 UE’s permanent identity private during over-the-air 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):

Logical Channel

Transport Channel

Physical Channel

RRC Connection Request CCCH RACH PRACH RRC Connection Setup CCCH FACH SCCPCH RRC Connection Setup Complete DCCH RACH 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 user’s 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 UE’s temporary identity (TMSI) is used. Using TMSI is preferred to keep the user’s permanent information private.

2) Establishment Cause – Conveys the reason for requesting the RRC Connection. In case of a user-originated 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.



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).

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)



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.


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.

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



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.


Figure 38: Examples of RRC Connection Setup Complete Messages

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 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



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



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



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

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



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 network’s 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:



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 UE’s dedicated physical channel (DPCH). It includes the frame and chip offsets to the Node B’s 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, real-time video, and interactive games)

Streaming – One-way transport to human destination (examples include real-time audio and real-time 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 user’s 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.



Traffic Class Conversational

Class Streaming Class Interactive Class Background Class

Fundamental characteristics

Preserve time relation (variation) between information entities of the stream. Conversational pattern (stringent and low delay)

Preserve time relation (variation) between information entities of the stream

Request response pattern. Preserve payload

Destination is not expecting the data within a certain time. Preserve payload content.

UMTS Delay Objectives

120 ms (TS 23.107)

200 ms (80% of UMTS

bearer)

320 ms (80% of UMTS

bearer)

800 ms (80% of UMTS

bearer) Example of Application

Voice Streaming Video Web browsing background download of emails

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) CS RAB PS RAB UL DL Type UL DL Type UL DL

3.4kbps 3.4kbps - - - Interactive/ Background 128kbps 128kbps


Streaming/ Unknown 16kbps 64kbps






SRB (for DCCH) CS RAB PS RAB UL DL Type UL DL Type UL DL


3.4kbps 3.4kbps Conversational/Unknown 12.2kbps 12.2kbps

Interactive/ Background 8kbps 8kbps




3.4kbps 3.4kbps Conversational/Unknown 12.2kbps 12.2kbps Interactive/

Background 128kbps 64kbps







3.4kbps 3.4kbps - - - Interactive/ Background 64kbps

Max bit rate dependent on UE category

3.4kbps 3.4kbps - - - Interactive/ Background 128kbps

Max bit rate dependent on UE category

Table 21: Lucent Radio Access Bearers (RABs)

Radio Bearer Setup

The purpose of the Radio Bearer Setup is to establish the UE’s 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.



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 circuit-switched 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.



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)



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 3G-SGSN. 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.



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.



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 UTRAN’s 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.

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



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.



4.3 Mobility and Connection Management

4.3.1 Load Control

4.3.1.1 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-to-interference 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 subscriber’s 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



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.

Lucent’s 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 Lucent’s 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:

where:

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:

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]

10/][101Load_UL dBNR−−=

][_][][ dBmfloornoisedBmRSSIdBNR −=

][max_/][__ WpwrWpwrcurrentTSSIDLload ==



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.



LCell measurementReporting eVENTTRIGGERED

pERIODIC eVENTTRIGGER

ED

This is set per RNC. This parameter indicates what type of measurement reporting is used. This parameter will not be modifiable for 03.01.

LCell hysteresisTime 2000ms 1000 to 30000 ms (in steps of

1000 ms)

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.

LCell measurementPeriodLong 15 min -35 to -10 [dB]

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.

LCell timeMeasureControl

120 (corresponds to

2:00:00)

0 to 1435 mins (in steps of 5

mins)

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 filterCoefficientUL cOEFF_6

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

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

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

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.



T1 T1

Measured entity

Time

Measurement Reports

Measurement Threshold 2

Measurement Threshold 1

T1 – Measurement Hysteresis Time

T1

Report A Report B Periodic Reports

Report A Periodic Report

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 thr_RSSI1 = 20 – 10log(100 – thrDBCUL) + noise_floor

o thr_RSSI2 = 20 – 10log(100 – thrCACUL) + noise_floor

o 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



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 thr_TSSI1 = thrDBCDL (DBC DL load threshold)

o thr_TSSI2 = thrCACDL (Call Admission Control load threshold)

o 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.



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



“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.



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”.

o 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.

o 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



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



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.

Cell DCH

If RACH load > rACHCongThresd or

FACH load > rFACHCongThresh ?

Use rthClearDLDCHFACH & rthClearULDCHFACH

Use rthConDLDCHFACH & rthConULDCHFACH

No yes

DL data rate < rthClearDLDCHFACH and

UL data rate < rthClearULDCHFACH

And tTrigDCHFACH timer expires

And DL BO < bOthDLDCHFACH

DL data rate < rthCongDLDCHFACH and

UL data rate < rthCongULDCHFACH And

tTrigDCHFACH timer expires

And DL BO < bOthDLDCHFACH

Move to CELL FACH mode

Another DCH to FACH transition is not allowed

for a previously reconfiguration until

tPendDCHFACH timer expires

Cell FACH

No

yes

Move to CELL DCH mode. Use “initialRateDLDCH” for DL RAB and 128

kbps for UL RAB (as default)

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

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.rcThresholdfor the time of fACHULBOTrafVolMeas.rcTimeToTrigger)

Is tInactFACHPCH expires without any DL or UL activities?

Move to URA_PCH mode

(*)

yes

No

Another CELL_FACH to URA_PCH transition is

not allowed for a previously

reconfiguration until tPendFACHPCH timer

expiresAny data

transmission

yes yes

Stay on CELL_DCH

NoNo

DL data rate is averaged over a period defined by avTimeRDLFACHDCHUL data rate is averaged over a period defined byavTimeRULFACHDCHDL 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.

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

*: 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.

At any time, a RRC connection release will move UE from CELL_DCH, CELL_FACH or URA_PCH to Idle mode

Figure 54 State Transition detailed diagram with parameter names



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

PS I/B

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

Speech + PS I/B

12.2 Speech + 64 UL / 384 DL

HSDPA max DL bit rate 1.8 Mbps

128 UL / HS HSDPA I/B UL 64 UL / HS

Table 23 Supported RAB in 03.01

Transport Channel Type Instance number

Defines Transport Channel Type

1 DCCH signaling at 3.4kbps 2 Voice - RAB subflow 1 3 Voice - RAB subflow 2 4 Voice - RAB subflow 3 5 64kbps CS 6 UL 64kbps/DL 64 kbps PS 7 UL 64kbps/DL 384 kbps PS 8 UL 32kbps/DL 32 kbps PS 9 UL 64kbps/DL 128 kbps PS 10 57.6kbps CS 11 8kbps PS 12 HSDSCH/64 Int+BG

13 - 17 RNC internal (non configurable)

18 HSDSCH/32 Int+BG 19 HSDSCH/128 Int+BG 20 UL 128k / DL 64k PS Int/BG 21 UL 128k / DL 128k PS Int/BG 22 UL 128k / DL 384k PS Int/BG



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



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



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.



LCell thrRACH 50% 0 to 100%

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

parameter name

parameter name in database

range Cingular Default description

measurementReporting (pERIODIC, eVENTTRIGGERED)

Event triggered

This parameter indicates what type of measurement reporting is used. This parameter will not be modifiable for U03.01 but be fixed as “event‐triggered”.

hysteresisTime 1000...30 000 [ms]1000 ms step

2000

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.

measurementPeriodLong 1 to 60 [min] 15

Interval of periodical load measurements for the estimation of the daily_low_RSSI measurements. Should not be a critical parameter.

Measurement Control related parameters

timeMeasureControl 0...1439 [min] (corresponding to 0:00 to 23:59)

120 This time value can be modified if the time of lowest traffic is known from service measurements of the network



filterCoefficientUL cOEFF_0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 17, 19

cOEFF_6

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. (value 6: about 0.75 seconds filter time constant)

filterCoefficientDL cOEFF_0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 17, 19

cOEFF_6

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)

thrCACUL 0...100 [%] 100%

Load threshold for the UL call admission control and UL dynamic bearer control for voice. Lower thresholds result in earlier blocking of new calls and will lower the overall system load. Due to problems with RSSI spikes during UE attaches it is recommended to turn off all UL threshold.

CAC Related

thrCACDL 0...100 [%] 75%

Load threshold for the DL call admission control and DL dynamic bearer control for 64k/ 128k PS service and voice. Lower thresholds result in earlier blocking of new calls and will lower the overall system load. The given value is a good trade‐off between blocking and service quality and between outage and overload for the lower rate DL PS service, respectively.

thrConCUL 0...100 [%] 100%

Load threshold for the UL congestion control. Higher thresholds would result in a higher probability to reach the instability condition and therefore to deteriorate the transmission quality for all data carriers. Due to problems with RSSI spikes during UE attaches its recommended to turn off all UL threshold.

thrConCDL 0...100 [%] 100%

Load threshold for the DL congestion control. Higher thresholds would result in a higher probability to reach the instability condition and therefore to deteriorate the transmission quality for all data carriers.

Congestion Control

conCWaitTime 100 to 10000 [ms] 100 ms step

2000

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.

DBC related parameters thrDBCUL 0...100 [%] 75%

Load threshold for the UL dynamic bearer control for 64k PS service. Lower thresholds result in earlier DBC blocking and will lower the overall system load. Due to problem with RSSI spikes during UE attaches it is recommended to turn off all UL threshold.



thrDBCDL 0...100 [%] 50%

Load threshold for the DL dynamic bearer control for 384k PS service. Lower thresholds result in earlier DBC blocking and will lower the overall system load. The given threshold is a good trade‐off between outage and overload for the 384k PS service.

ecI0thr ‐24.0 to 0 [dB] ‐13

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. Decreasing this value will extend the area where 384k calls can be initiated but will also reduce system capacity (number of users).

stateTrans.directDCHPCH True/False FALSE

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.

State Transition Control

stateTrans.directPCHDCH True/False FALSE

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.

rACHCongThresh 0 to 8 2 Threshold for determining if a Cellʹs RACH channel is in a congested state.

fACHCongThresh 0 to 100 90 Threshold for determining if a Cellʹs FACH channel is in a congested state.

RACH/FACH Congestion

fACHOccupancyReportRate

0 to 10 000 [TTI] 1000 Parameter defines the interval in which FACH measurements are reported to RRC.

rthClearDLDCHFACH 0 to 100 000 [bps] 2500 Downlink data rate threshold for CELL_DCH to CELL FACH transition when the FACH is not in congested state.

rthClearULDCHFACH 0 to 100 000 [bps] 2500 Uplink data rate threshold for CELL_DCH to CELL_FACH transition when the RACH is not in congested state.

rthConDLDCHFACH 0 to 100 000 [bps] 2000 Downlink data rate threshold for CELL_DCH to CELL_FACH transition when the FACH is in congested state.

rthConULDCHFACH 0 to 100 000 [bps] 2000 Uplink data rate threshold for CELL_DCH to CELL_FACH transition when the RACH is in congested state.

avTimeRDLDCHFACH 0 to 10 000 [ms] 3000 Averaging period for DL rate measurement in CELL_DCH.

avTimeRULDCHFACH 0 to 10 000 [ms] 3000 Averaging period for UL rate measurement in CELL_DCH.

nSampRateDCHFACHDataRate 0 to 1 000 [10ms] 12

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.

tPendDCHFACH 0 to 16000 step 20 [ms]

2000

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.

Cell_DCH to Cell_FACH

tTrigDCHFACH 0 to 10 000 step 100[ms]

2000

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.



bOthDLDCHFACH 0 to 65535 [byte] 125 Threshold for unfiltered downlink buffer occupancy being below this value before transition from CELL_DCH to CELL_FACH.

rthDLFACHDCH 0 to 100 000 [bps] 3000 Downlink data rate threshold for transitioning from CELL_FACH to CELL_DCH.

rthULFACHDCH 0 to 100 000 [bps] 3000 Uplink data rate threshold for transitioning from CELL_FACH to CELL_DCH.

avTimeRDLFACHDCH 0 to 100 000 step 1000 [ms]

10000 Averaging period for DL rate measurement in CELL_FACH.

avTimeRULFACHDCH 0 to 100 000 step 1000 [ms]

10000 Averaging period for UL rate measurement in CELL_FACH.

avTimeBODLFACHDCH 0 to 10 000 [ms] 200 Average period for DL buffer occupancy measurement in CELL_FACH.

nSampRateFACHDCHDataRate

0 to 1 000 [10ms] 12

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.

nSampRateDLBOFACHDCH

0 to 1 000 [10ms] 4

Parameter defines the granularity of the downlink buffer occupancy moving average filter measured in CELL FACH for filter measured in CELL_FACH for CELL_FACH to CELL_DCH transition.

bOthDLFACHDCH 0 to 65535 [byte] 500 Downlink buffer occupancy threshold for transitioning from CELL_FACH to CELL_DCH.

tPendFACHDCH 0 to 16000 step 20 [TTI]

2000

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.

tTrigBOFACHDCH 0 to 10 000 [ms] 0

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.

tTrigRateFACHDCH 0 to 10 000 step 100 [ms]

1000

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.

Cell_FACH to Cell_DCH (RNC trigger)

dCCHBuffOccupancy Multiplier

0 to 5000 step 0.1 1

Parameter defines a scaling on the DCCH for buffer occupancy trigger from CELL_FACH to CELL_DCH. 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.

Cell_FACH to Cell_DCH (UE trigger)

fACHULBOTrafVolMeas. measQtyqty

rLCBUFFERPAYLOAD, aVERAGERLCBUFFERPAYLOAD, vARIANCEOFRLCBUFFERPAYLOAD

aVERAGERLCBUFFERPAYLOAD

Measurement type for a traffic volume measurement.



fACHULBOTrafVolMeas.measQyaverageTime

20 to 260 step 20 [ms]

200

Time interval to take an average or a variance on a traffic volume measurement. Note: only valid for Average RLC buffer payload and Variance of RLC buffer Payload measurement quantity.

fACHULBOTrafVolMeas.measValidity

cELLDCH, aLLBUTCELLDCH, aLLSTATES

aLLBUTCELLDCH Indicates the states in which traffic volume measurement reporting shall be conducted.

fACHULBOTrafVolMeas.rcMeasPendingTriggerTime

tIMEAFTERTRIGGER_0, 250, 500, 1000, 2000, 4000, 8000, 16000

tIMEAFTERTRIGGER_1000

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.

fACHULBOTrafVolMeas. rcThreshold

tRAFFICVOLUMETHR_8, 16, ...1024, 2K, 3K, ....384K, 512K, 768K

tRAFFICVOLUMETHR_512

Reporting threshold for buffer occupancy in CELL_FACH.

fACHULBOTrafVolMeas.rcTimeToTrig

tIMETOTRIGGER_0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000

tIMETOTRIGGER_0

Indicates the period of time between the timing of event detection and the timing of sending a traffic volume Measurement Report. Note that 0 removes the quantity from the SIB.

fACHULBOTrafVolMeas.rcTxInterruptTime

tIMEAFTERTRIGGER_0, 250, 500, 1000, 2000, 4000, 8000, 16000

tIMEAFTERTRIGGER_250

Indicates how long the UE will block DTCH transmissions on the RACH after the measurement report is triggered. Note that 0 removes the quantity from the SIB.

fACHULBOTrafVolMeas. repMode

aM_RLC, uM_RLC

aM_RLC Traffic Volume Measurement Report Transfer Mode on the DCCH.

tInactFACHPCH 0 to 1000 [s] 100 Inactivity timer from CELL_FACH to URA_PCH transition.

Cell_FACH to URA_PCH

tPendFACHPCH 0 to 16000 step 20 [TTI]

2000

Indicates the period of time during which it is forbidden to send any new FACH to PCH measurement reports even if the triggering condition is fulfilled.

URA_PCH to Cell_FACH tPendPCHFACH

0 to 16000 step 20 [ms]

2000

Indicates the period of time during which it is forbidden to send any new PCH to FACH measurement reports even if the triggering condition is fulfilled.

bOAverageTimeDLDCH 0 to 2000 step 20 [ms]

200 Averaging time for the buffer occupancy measurement.

bOthrDLDCH 0 to 65535 [byte] 0 means disabled

1400

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.

bOTimeToTriggerDLDCH 0 to 10000 step 20 [ms]

0 Time hysteresis before the first buffer occupancy measurement is triggered.

Rate Reconfiguration Parameters

bOPendingTriggerTimeDLDCH

0 to 16000 step 20 [ms]

2000

Time hysteresis before a consecutive buffer occupancy measurement is triggered. So this defines the minimum time between two consecutive rate increases.



initialRateDLDCH

dataRateDLDCH_8 dataRateDLDCH_32 dataRateDLDCH_64 dataRateDLDCH_128 dataRateDLDCH_384

dataRateDLDCH_384

The initial downlink data rate taken by DBC when moving from URA_PCH to CELL_DCH.

rateAverageTimeDLDCH 0 to 30000 step 100 [ms]

0 Averaging time for the data rate measurement.

relativeRateThrDLDCH 0 to 100 [%] 0 means disabled

0

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)

rateTimeToTriggerDLDCH 0 to 10000 step 100 [ms]

0 Time hysteresis before the first rate measurement event is triggered.

ratePendingTriggerTimeDLDCH

0 to 16000 step 20 [ms]

2000

Time hysteresis before a consecutive rate measurement event is triggered. So this defines the minimum time between two consecutive service based rate decreases.

bLERWindowLength 1 to 512 [# of TBs]

180

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.

bLERthr 0 to 100 [%] 10%

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.

bLERPendingAfterTrigger 1 to 512 [# of TBs]

480

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.

rABInactivityTimer 0 to 65535 [seconds] 0 means disabled

5 Time after which the UE may be sent to URA_PCH state in case of inactivity on both links (UL/DL).

Data rate decrease related parameters

minReduceRateDLDCH

pSRateDLDCH_8, pSRateDLDCH_32, pSRateDLDCH_64, pSRateDLDCH_128, pSRateDLDCH_384

pSRateDLDCH_64 The minimum DCH downlink data rate for service triggered data rate downgrade.

thrCACDL 0….100 100%

Load threshold for the DL call admission control, if DL power control is not working. CAC is essentially disabled to relief the very tight capacity issues.

CAC/DBC/ConC Parameters for faulty DL power control [some of the early UEs do not properly support DL

thrConCDL 0….100 100%

Load threshold for the DL congestion control, if DL power control is not working. ConC is essentially disabled to relief the very tight capacity issues.



power control]

thrDBCDL 0…100 100%

Load threshold for the DL dynamic bearer control, if DL power control is not working. DBC is essentially disabled to relief the very tight capacity issues.

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: Cingular’s choice on parameter value based on latest strategy

and/or field study. Access Rules RW The parameter is read-write RO The parameter is read-only RO‐SC The parameter is writable at creation then it is read-only RW‐LO The parameter is read-write only when the object is locked RW‐PL The parameter is read-write only when parent object is locked RW‐EL The parameter is read-write only when top-level object is locked RW‐DC DC = Direct Connect (parameters are adjustable via LMT, only). LMT = Local Maintenance Terminal Access Interface

RNC‐CLI 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’.

OMC The (Node B or RNC) parameter is accessible via OMC-U Most of these parameters are RNC CLI accessible only. For these parameters, the general recommendation is not to change them from Cingular default until further notice from HQ. It is believed that such parameters have been optimized using advanced simulation and work well in normal traffic conditions. Further monitoring of network performance and trials will be run to study these parameters. Notification will be issued to the audience of this field guide for any updated value. This section is intended to provide guidance on OMC accessible parameters and RNC CLI parameter that are most relevant to network performance and customer experience. For all the



other “less important” RNC CLI accessible only parameters, refer to parameter excelsheet in section 7.1, this field guide and Lucent Load Control TAN. It is strongly recommended not to modify the CLI only parameters as these are sensitive parameters with high impact on performance. For OMC accessible parameters, current recommendations should be followed and alternation should be coordinated by HQ and Regional leads. Load Estimation Parameters Filter Coefficient DL

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.

Filter Coefficient UL

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.

Hysteresis Time

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.

Measurement Period Long



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.

Measurement Reporting

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”.

Time Measure Control

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

Admission Control Parameters DL Call Admission Control Threshold

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

UL Call Admission Control Threshold

Parameter Name in database: thrCACUL



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)

Congestion Control Parameters Congestion Wait Time

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.

DL Congestion Control Threshold

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.

UL Congestion Control Threshold

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.



Dynamic Bearer Control (DBC) Parameters DL DBC Threshold

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%

EcIo Threshold

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.

UL DBC Threshold

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).

State Transition Parameters State Transition Control Direct DCH to PCH transition

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 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.

Direct PCH to DCH transition

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/FACH Congestion FACH congestion threshold

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.

RACH congestion threshold

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.

Cell DCH to FACH transition Average Time DL DCH to FACH data rate measurement

Parameter Name in database: avTimeRDLDCHFACH



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.

Average Time UL DCH to FACH data rate measurement

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.

Buffer Occupancy threshold for DL DCH to FACH transition

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.

Number of Samples in data rate measurement averaging for DCH to FACH transition

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)

Rate threshold for DL DCH to FACH transition with Clear FACH



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.

Rate threshold for UL DCH to FACH transition with Clear RACH

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.

Rate threshold for DL DCH to FACH transition with congested FACH

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.

Rate threshold for UL DCH to FACH transition with congested RACH

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.

Time Pending for new DCH to FACH transition

Parameter Name in database: tPendDCHFACH 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 DCH to FACH measurement reports even if the triggering condition is fulfilled. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 2000 ms

Time To Trigger for DCH to FACH transition

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

Cell FAH to DCH transition (RNC triggered) Average Period DL BO measurement for FACH to DCH transition

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.

Average Period DL data rate measurement for FACH to DCH transition

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.



Average Period UL Data Rate measurement for FACH to DCH transition

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.

Buffer Occupancy threshold for DL FACH to DCH transition

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.

Buffer Occupancy multiplier for DL FACH to DCH transition

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.

Number of Samples in data rate measurement averaging for FACH to DCH transition

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



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)

Rate threshold for DL FACH to DCH transition

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.

Rate threshold for UL FACH to DCH transition

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.

Time Pending for new FACH to DCH transition

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

Time To Trigger for FACH to DCH transition

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 FACH to DCH measurement report for data rate measurements. Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: 1000 ms

Time To Trigger for DCH to FACH transition using BO

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

Cell FAH to DCH transition (RNC triggered) BO threshold for UL FACH to DCH transition

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

Time Pending for new FACH to DCH transition using UL BO measurement

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)

Time To Trigger for FACH to DCH transition using UL BO measurement

Parameter Name in database: fACHULBOTrafVolMeas.rcTimeToTrig Access in OMC GUI: RNC CLI only. RW



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)

Cell FAH to URA_PCH transition and URA_PCH to CELL FACH transition Inactivity Timer for CELL_FACH to URA_PCH transition

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

Time pending for new CELL_FACH to URA_PCH transition

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

Time pending for new CELL_FACH to URA_PCH transition

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

Data Rate Adaptation Parameters Average Time for Data Rate measurement



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

BO Average Time DL DCH

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

BO threshold for DL DCH rate increase

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

BO Time To Trigger for DL DCH rate increase

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

BO Pending time to trigger for new DL DCH rate increase

Parameter Name in database: bOPendingTriggerTimeDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 16000 step 20 [ms] Granularity: per RNC



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

BLER Window Length for DL BLER measurement

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

BLER Threshold for DL DCH Data Rate decrease

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%

BLER Pending Time for DL DCH Data Rate decrease

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

Data Rate Relative Threshold to trigger DL DCH rate decrease

Parameter Name in database: relativeRateThrDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 100 [%] 0 means disabled Granularity: per RNC



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

Inactivity Timer of RAB to trigger DCH to URA_PCH transition

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

Initial DL DCH Data Rate

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

Minimum DL DCH allowed in Data Rate decrease

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

Time to Trigger for DL DCH Data Rate Decrease

Parameter Name in database: rateTimeToTriggerDLDCH Access in OMC GUI: RNC CLI only. RW Unit & Range: 0 to 10000 step 100 [ms] Granularity: per RNC



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



4.3.2 Power Control

4.3.2.1 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:

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.

S BS

MS1

MS2

If the power of MS1 is not properly controlled it will jam the weaker signal of MS2



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 other-cell 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.



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



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:

Figure 60 Use Open Loop PC for initial power of DL/UL DPCCH

4.3.2.5 UL Open Loop Power Control

4.3.2.5.1 PRACH preamble & message part power determination

This has been explained in section 4.2.2.1.2.

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:

Decided by UL Open loop

DCCH (logical channel) is mapped to DCH transport channel DCH is then mapped to DPCCH/DPDCH physical channels

PRACH power Decided by UL Open loop PC

Decided by DL Open loop PC



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.



• 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 PO’s 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:



• 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 DL Closed Loop Power Control

4.3.2.7.1 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:



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



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 UL Closed Loop Power Control

4.3.2.8.1 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:

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes/Customer_UMTS_RF_TAN_U03.01_Power_Control.pdf



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



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.



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 one of them shall be 15 and the power ration between DPDCH and DPCCH is (βd/βc)2. 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.




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.



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:

o 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. .

o 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”.

o 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 if X > 0

Sgn (X) = 0 if X = 0 Sgn (X) = -1 if X < 0

CFN = Connected Frame Number Pinit = P(i) described above



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)



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.

o Synchronization Channel (SCH) with sub-channels Primary SCH and Secondary SCH.



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. It’s power is set to a relative value to P CPICH and defined by parameter “aICHPower”. It’s 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%.



4.3.2.11 Engineering Guideline for IRAT related parameters

4.3.2.11.1 Summary table

parameter name parameter name in

database range Cingular default description

EcNotarget (prev. slRTarget)

‐24.0, ‐23.9...+1.5 UEGTFCS Instance : (1, 2, 3, 4, 5, 6, 7, 9, 11, 13, 14 = ‐19.0dB) (31, 32, 33, 34, 35, 36 = ‐18.0dB)

as per UEGTFCS Used for the calculation of the initial transmit power of the first radio link.

dLPowerMargin ‐10, ‐9.9, …+10 3

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.

Downlink Open Loop Power Control

newLegPowerOffset

0, 0.1, ….25.5 UEGTFCS Instance : ( 1, 2, 4, 5, 6, 7, 9, 11 = +5dB) (3, 13, 14, 31, 32, 33, 34, 35, 36 = +6dB)

as per UEGTFCS Used for the calculation of the initial transmit power of the radio links other than the first one.

Downlink Outer Loop Power Control bLERQualityTarget

‐6.3, ‐6.2 … 0 Ded Tr Channel instance : (1 = ‐2 (1%)) (2, 3, 4 = ‐2.1 (0.7%)) (5 = ‐3 (0.1%)) (6, 7, 9, 20, 21, 22 = ‐1.3 (5%))

as per UEGTFCS It provides the Downlink BLERtarget.

limitedDLPowerIncrease True/False

TRUE (all others) False (DTCH=

2,3,4,5)

Indicates whether DL power increase limitation is allowed for the DPDCH where it is mapped

PowerRaiseLimit [0,10] 10 Parameter for the DL Power Increase Limitation algorithm.

DLPowerAvWindowSize

[1,60] 15 Parameter for the DL Power Increase Limitation algorithm.

Downlink Inner Loop Power Control

tPCStepSize

{TPC0‐5 = 0.5, TPC1‐0 = 1, TPC1‐5 = 1.5, TPC2‐0 = 2}

TPC1‐0 It defines the adjustment step specified in the downlink power control commands.

dPCMode sINGLETPC sINGLETPC It defines the Downlink Power Control modes supported by the UE.

minDLPower ‐35, ‐34.9 … +15 ‐19 Minimum downlink power level for a given code power.

Downlink power control mode parameter

maxDLPower

‐35, ‐34.9 … +15 UEGTFCS instance : (1, 4, 13, 31, 50, 54 = +3dB) (2 = 0 dB) (9, 32 = 4 dB) (Others = +6dB)

follows UEGTFCS

Maximum downlink power level for a given code power.



PminCorrectionFactor

‐10.0, ‐9.9 … +10 0

Local correction to the value of minDLPower used to define the DL dynamic range of dedicated radio links on a cell basis.

PmaxCorrectionFactor

‐10.0, ‐9.9 … +10 0

Local correction to the value of maxDLPower used to define the DL dynamic range of dedicated radio links on a cell basis.

ImbalanceCorrection

TRUE Defines if imbalance correction of downlink transmit power should be activated or not.

maxAdjustmentStep

[1, …10] slots 2

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.

adjustmentPeriod [1, 2, … 256] frames 1

Maximum time allowed for the application of the balance correction which value has been calculated at the beginning of the correction period.

scaleAdjustmentRatio

[0 … 100] 50 Defines the convergence rate used for the associated Adjustment Period.

Power Imbalance

dLReferencePower

[‐35, ‐34.9…+15] UEGTFCS instance : (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

Reference Power level for imbalance correction algorithm

pO1 (0.0, 0.25…,6.0) 0

Power offset for the TFCI bits. Values greater than zero for TFCI power offset may improve the BLER performances.

pO2ForOneRLSet (0.0, 0.25…,6.0) 0

Power offset for the TPC bits when there is only one radio link set connected to the UE. Values greater than zero for this offset may reduce the TPC command error detection rate.

pO2ForTwoRLSet (0.0, 0.25…,6.0) 3

Power offset for the TPC bits when there are two radio links set connected to the UE. Values greater than zero for this offset may reduce the TPC command error detection rate.

Downlink DCH power offsets parameters.

pO2ForThreeRLSetAndMore

(0.0, 0.25…,6.0) 6

Power offset for the TPC bits when there are three radio links set connected to the UE. Values greater than zero for this offset may reduce the TPC command error detection rate.



pO3 (0.0, 0.25…,6.0) 2

Power offset for the pilot bits. Current default value for pilot power offset improves the UE synchronization and increases the downlink capacity gain.

Deactivation of the downlink inner loop

power control innerLoopPCStatus TRUE Activate / deactivated the inner loop

power control feature.

deltaSIR1 0, 0.01, 3 0

during the frame containing the start of the first transmission gap in the transmission gap pattern (without including the effect of the bit‐rate increase). This Delta will be applied to the uplink/downlink transmission power control procedure.

deltaSIRAfter1 0, 0.01, 3 0

Delta SIR target value to be set in the Node‐B one frame after the frame containing the start of the first transmission gap in the transmission gap pattern.

deltaSIR2 0, 0.01, 3 0

Delta SIR target value to be set in the Node‐B during the frame containing the start of the second transmission gap in the transmission gap pattern (without including the effect of the bit‐rate increase). When omitted, DeltaSIR2 = DeltaSIR1.

Downlink power control in compressed

mode


Delta SIR target value to be set in the Node‐B one frame after the frame containing the start of the second transmission gap in the transmission gap pattern. When omitted, DeltaSIRAfter2 = DeltaSIRAfter1

pCPICHpower ‐10, ‐9.9, …+50 36

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.

pSCHpower ‐35.0, ‐34.9, … +15.0 ‐3

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%).

POWER SETTINGS FOR DOWNLINK

COMMON CHANNELS

sSCHpower ‐35.0, ‐34.9, … +15.0 ‐5

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%).



bCHPower ‐35.0, ‐34.9, … +15.0 ‐3

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%).

secondaryCCPCH.powerOffset1

0.0, 0.25, … 6.0

Power offset of the Secondary CCPCH TFCI field relative to the transmission power of the data part (PCH or FACH). Values greater than zero for TFCI power offset may improve the BLER performances


0.0, 0.25, … 6.0 0

Power offset of the Secondary CCPCH pilot field relative to the transmission power of the data part (PCH or FACH). Values greater than zero for pilot power offset may help the UE to achieve synchronization and perform a better reception of the S‐CCPCH.

pCHPower ‐35.0, ‐34.9, … +15.0 4 PCH power, in dB with respect to P‐CPICH power

pICHPower ‐10,‐9.9, … +5 ‐7 PICH power, in dB with respect to P‐CPICH power

fACHTrafPower ‐35.0, ‐34.9, … +15.0 ‐2 FACH power, in dB with respect to P‐CPICH power.

fACHSigPower ‐35.0, ‐34.9, … +15.0 4 FACH power, in dB with respect to P‐CPICH power


0.0, 0.25, … 6.0 0 Same as for the SCCPCHPch


0.0, 0.25, … 6.0 0 Same as for the SCCPCHPch

aICHPower ‐22, ‐21.9, … +5 ‐6

Defines the output power level of the AICH physical channel, in dB with respect to P‐CPICH power. Current setting ensure successful decoding at the UE of AI messages along RACH Access procedures.

dPCCHPowerOffset

‐164, ‐162…‐6 ‐84 Used to determine initial transmit power of a new DTCH. Value expressed in dB.

pCPreamble 0..7 7

Indicates length of power control preamble. Expressed in number of radio frames. No PC preamble is currently used to delay uplink DPDCH transmission after uplink DPCCH transmission. The reason is that some UEs crash if the value is other than 0.

Uplink Open Loop Power Control

qESelector

Y=”selected”, N=”non‐selected” Ded Transport Channel instance : (All except 3 and 4 = Y) (3 and 4 = N)

follows Ded Transport

channel selected

It defines the metric to be selected for radio link quality estimation. This settings means that the selected metric for radio link quality estimation is the Physical Channel BER.



downSIRStep

0.000,0.001… 0.512 Ded Transport channel instance : (1 = 0.002) (2, 5 =0.001) (3, 4 = 0) (6, 7, 9, 20, 21, 22 = 0.01)


channel selected

upSIRStep

0.000,0.001… 0.512 Ded Transport channel instance : (1, 5, 6, 7, 9, 20, 21, 22 = 0.2) (2 = 0.15) (3, 4 = 0)


channel selected

It defines the uplink SIRtarget decrement step in dB. Current values ensure quick OLPC reaction in highly variable RF environment without causing spikes in SIRtarget.

qEThreshold

0.0, 1,0….255.0 Ded Transport Channel instance : (1, 3, 4 = 255.0) (2, 5, 6, 7, 9 = 130.0) (20, 21, 22 = 150.0)


channel selected

It defines the QE threshold for allowing decrement of SIRtarget in dB. This value disables the check in OLPC on the Quality Estimation, thus OLPC decision on SIRtarget calculation are based only on CRC check results.

sIRAllowance 0,0.1….10 0 It defines the hysteresis factor used to restrict SIR target update in dB.

sIRDownAdditional

0.000,0.001… 0.512 Ded Transport channel instance : (1 = 0.4) (2 = 0.025) (3, 4 = 0) (5, 6, 7, 9, 20, 21, 22 = 0.05)


channel selected

Extra UPLINKSIR target decrement when a Transport block is received with CRCI = ok. Used when High Speed SIR Target Decrease is active.

NbOfConsecutiveGoodFramesThreshold

[0,1 .255] Ded Transport channel instance : (1, 6, 7, 9 = 120) (2, 3, 4 = 250) (5 = 200) (20, 21, 22 = 160)


channel selected

Threshold for activation of High Speed SIR Target Decrease

initialSIRTarget

‐8.2, ‐8.1, … +17.3 UEGTFCS instance : (All Except 2, 3, 13, 14 =+7dB) (2 = +5dB) (3, 13, 14 = +6dB)

follows UEGTFCS

Initial SIRtarget for the considered radio bearer expressed in dB. Setting depends on power imbalance and DL OLPC issues. Should be further optimized in order to minimize the convergence time, hence the uplink power consumption & noise rise during the transient period.

SIR target related parameters

minSIRTarget

‐8.2, ‐8.1, … +17.3 UEGTFCS instance : (All Except 3 = 0dB) (3 = +4.9dB)

follows UEGTFCS

Minimum SIR target for considered radio bearer in dB.



maxSIRTarget

‐8.2, ‐8.1, … +17.3 UEGTFCS instance : (All Except 2, 13, 14, 31, 32, 33, 34, 35, 36 = +8dB) (2, 13, 14 = +7dB) (31, 32, 33, 34, 35, 36 = +9dB)

follows UEGTFCS

Maximum SIR target for considered radio bearer in dB.

tPCStepSizeUL 0 (1.0dB), 1 (2.0dB) 0 Adjustment step specified in the uplink power control commands 0 means 1dB, 1 means 2dB steps.

maxULDPCHPower

‐50, ..,+33 33

This is the highest permitted value ensuring maximum uplink coverage. It may be decreased in case of uplink interference issues.

Uplink power control step size and UE transmit power limit parameters.

PowerControlAlgorithm

(pCALGORITHM‐1, pCALGORITHM‐2)

pCALGORITHM‐1

It specifies the algorithm to be used by UE to interpret TPC commands

TFC0.gainFactorBc 0…15 12

It defines the DPCCH gain given for the highest rate of the Transport Format Combination Structure (TFCS). Current values help to mitigate the power imbalance effects by increasing both DPCCH and DPDCH performances without causing high uplink power consumption.

TFC0.gainFactorBd 0…15 15

It defines the DPDCH gain given for the highest rate of the TFCS. Current values help to mitigate the power imbalance effects by increasing both DPCCH and DPDCH performances without causing high uplink power consumption

TFC1.gainFactorBc 0…15 12

It defines the DPCCH gain given for the highest rate of the Transport Format Combination Structure (TFCS). Current values help to mitigate the power imbalance effects by increasing both DPCCH and DPDCH performances without causing high uplink power consumption.

TFC1.gainFactorBd 0…15 15

It defines the DPDCH gain given for the highest rate of the TFCS. Current values help to mitigate the power imbalance effects by increasing both DPCCH and DPDCH performances without causing high uplink power consumption

gainFactorType (sIGNALLED, cOMPUTED)

sIGNALLED It defines the method to either directly signalling or computing the gain factors.

Uplink inner loop power control ‐ DPCCH/DPDCH power gains parameters.

referenceTFC ‐ 1 It defines the reference number in case computed method is used.



deltaSIR1 0, 0.01, 3 0

Delta SIR target value to be set in the UE during the frame containing the start of the first transmission gap in the transmission gap pattern (without including the effect of the bit‐rate increase). This Delta will be applied to the uplink/downlink transmission power control procedure.


Delta SIR target value to be set in the UE one frame after the frame containing the start of the first transmission gap in the transmission gap pattern.

deltaSIR2 0, 0.01, 3 0

Delta SIR target value to be set in the UE during the frame containing the start of the second transmission gap in the transmission gap pattern (without including the effect of the bit‐rate increase). When omitted, DeltaSIR2 = DeltaSIR1.

Compressed Mode Parameters


Delta SIR target value to be set in the UE one frame after the frame containing the start of the second transmission gap in the transmission gap pattern. When omitted, DeltaSIRAfter2 = DeltaSIRAfter1

Power overload control parameter.

maxTransmissionPower

30.0, 30.1….46.0 46 Maximum downlink power, in dBm allowed in the cell.

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



and/or field study. Access Rules

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and%25



RW The parameter is read-write RO The parameter is read-only RO‐SC The parameter is writable at creation then it is read-only RW‐LO The parameter is read-write only when the object is locked RW‐PL The parameter is read-write only when parent object is locked RW‐EL The parameter is read-write only when top-level object is locked RW‐DC DC = Direct Connect (parameters are adjustable via LMT, only). LMT = Local Maintenance Terminal Access Interface


OMC The (Node B or RNC) parameter is accessible via OMC-U

UEGTFCS Instance and associated service combination



Dedicated Transport Channel Instances and associated radio bearer



DL Open Loop Power Control Parameters Ec No Target

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

DL Power Margin

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.

New Leg Power Offset

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).

UL Open Loop Power Control Parameters DL DPCCH Power Offset

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.



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 .

Power Preamble

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

DL Inner Loop Power Control Parameters DL Power Average Window Size

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: 1…60 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

DL Power Control Mode

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

Limited DL Power Increase

Parameter Name in database: limitedDLPowerIncrease Access in OMC GUI: RNC CLI, per UEGTFCS, RW-EL



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

Maximum DL Power

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)

Minimum DL Power

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)

Power Raise Limte

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

Power Offset 1

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



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)

Power Offset 2 for One RL Set

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)

Power Offset 2 for Two RL Set

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)

Power Offset 2 for Three RL Sets or more

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)

Power Offset 3

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)

TPC Step Size



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)

DL Outer Loop Power Control Parameters BLER Quality Target

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

UL Inner Loop Power Control Parameters Maximum UL DPCH Power

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

Power Control Algorithm

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



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

TPC Step Size UL

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.

UL Outer Loop Power Control Parameters Initial SIR Target

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

Maximum SIR Target

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)



Minimum SIR Target

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

DL Power Balancing Parameters Adjustment Period

Parameter Name in database: adjustmentPeriod Access in OMC GUI: RNC CLI Only, In UL DPCH info object table. RW-EL Unit & Range: 1…256 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)

DL reference power

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)

Imbalance Correction

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



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

Maximum Adjustment Step

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

Scale Adjustment Ratio

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.

DL Common Channel Power Setting Parameters AICH Power

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 P-CPICH 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

BCH power

Parameter Name in database: bCHPower



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.

FACH Traffic Power

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.

FACH Signaling Power

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.

FACH power offset 1

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

FACH power offset 2

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).



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

P‐CPICH Power

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.

PCH Power

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.

PICH power

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

PCH power offset 1

Parameter Name in database pch.secondaryCCPCH.powerOffset1 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: Engineering Recommendation: 0 dB.

PCH Power offset 2

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.

P‐SCH power

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

S‐SCH power

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, S-SCH could have less power than P-SCH. Engineering Recommendation: - 5 dB



4.3.3 Soft/Softer Handovers


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 UE’s 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



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.

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes



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 Lucent’s UMTS RF Translation Application Note: Handover U03.01 Version 5.0.

4.3.3.3 Measurement Control and Reporting

4.3.3.3.1 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.



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;



• 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 event-triggered 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:



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 don’t 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.



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)



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) Lucent’s 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;



• 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

parameter name in database range Cingualr

Default description

addThresholdSHO 0..65535 4

Threshold applied in the RNC to determine which cells (from all those reported by the UE on the RACH) are finally to be included in the active set at call set‐up.

reportingCriteria1A.rcamtOfRep

1,2, 4, 8, 16, 32, 64, INFINITY)

INFINITY

reportingCriteria1B.rcamtOfRep

(1, 2, 4, 8, 16, 32, 64, INFINITY)

64

reportingCriteria1C.rcamtOfRep

(1, 2, 4, 8, 16, 32, 64, INFINITY)

INFINITY

Maximum number of reports to be sent by the UE when the events 1A, 1B, 1C are triggered. It is split in three sub‐fields per event type

reportingCriteria1A.rcReportingCriteria

(0, 250, 500, 1000, 2000, 4000, 8000, 16000)

1000

Triggering conditions and reporting rules ‐ Cell DCH State

reportingCriteria1B.rcReportingCriteria

(0, 250, 500, 1000, 2000, 4000, 8000, 16000)

1000

reportingCriteria1C.rcReportingCriteria

(0, 250, 500, 1000, 2000, 4000, 8000, 16000)

1000

It defines the report periodicity when the events 1A, 1B, 1C are triggered. It is split in three sub‐fields per event type

active

set

size

ActiveSetSizeCS 2…. 6 step of 1

4 Maximum size of the active set for CS applications



ActiveSetSizePS 2…. 6 step of 1

3 Maximum size of the active set for PS applications

reportingCriteria1A.reportingRange

(0.0 … 14.5) [dB] 0.5 dB step

4

reportingCriteria1B.reportingRange

(0.0 … 14.5) [dB] 0.5 dB step

6

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.

reportingCriteria1A.hysteresis

(0.0 … 7.5) [dB] 0.5 dB step

1

reportingCriteria1B.hysteresis

(0.0 … 7.5) [dB] 0.5 dB step

1

reportingCriteria1C.hysteresis

(0.0 … 7.5) [dB] 0.5 dB

step 2

Hysteresis parameter to limit the amount of event‐tirggered measurement reports. Secondary hysteresis applied to the main hysteresis. It applies to events 1A, 1B and 1C and it is split in three sub‐fields per event type. In Event 1C it is the only existing hysteresis.

reportingCriteria1A.timeToTrigger

(0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560,5000) [msec]

0

reportingCriteria1B.timeToTrigger

(0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560,5000) [msec]

1280

reportingCriteria1C.timeToTrigger

(0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000) [msec]

320

Period of time between detection of event and sending of measurement report. Period of time that delays the event triggering. It applies to events 1A, 1B and 1C and it is split in three subfields per event type.

reportingCriteria1A.w (0.0…2.0) 0.1 step

0

Reporting event condition related parameters ‐ Cell DCH State

reportingCriteria1B.w (0.0…2.0) 0.1 step

0

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. It applies to events 1A and 1B and it is split in two sub‐fields per event



type.

outFDDAdjCells.cellOffset

(‐10.0 … 10.0) [dB] 0.5 dB step

0

Offset (positive or negative) added to the measurement quantity. It applies to events 1A, 1B and 1C on a per cell basis.

combinedNeighbourhoodListSize

[1..32] 32 Maximum number of neighbour cells to be included in the list produced by the NLSA.

NLSA related parameter

s outFDDAdjCells.nLSAPriority

(lOW, mEDIUM, hIGH, vERYHIGH)

mEDIUM This parameter defines the NLSA priority of the neighbour cell. It is set on a per neighbour basis.

UE Active Set Update ResponseTimer

UEActiveSetUpdateResponseTimer

(0. ..50000) [msec] 1 sec step

15000

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

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.



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



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 UE’s 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



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



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



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.0…2.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.0…2.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.0…2.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:



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: 1…32 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)



4.3.4 HSDPA


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.



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=8

SF=16

SF=4

SF=2

Physical channels (codes) to which HS-DSCH is mapped CPICH etc.

C16,0 C16,15



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

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

Data to UE #1 Data to UE #2 Data to UE #3

Time (per TTI)

Code

not used



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.



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 HS-PDSCH. 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



– 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.

HS-DSCH Category

Maximum number of HS-DSCH multi-codes

Minimum inter-TTI interval

Maximum MAC-hs TB size (bits)

Theoretical maximum PHY data rate (Mbit/s)

Category 1 5 3 7298 1.2

Category 2 5 3 7298 1.2

Category 3 5 2 7298 1.8

Category 4 5 2 7298 1.8

Category 5 5 1 7298 3.6

Category 6 5 1 7298 3.6

Category 7 10 1 14411 7.2

Category 8 10 1 14411 7.2

Category 9 15 1 20251 10.1

Category 10 15 1 27952 14

Category 11* 5 2 3630 0.9

Category 12* 5 1 3630 1.8

*: category 11 and 12 only support QPSK mode. All other categories support both QPSK and 16QAM

4.3.4.2.4 HSDPA Service Combinations

Lucent’s 03.01 UTRAN supports the following service combinations with HSDPA in the downlink direction.

Figure 78 Service Combinations for HSDPA



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 CED’s 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 Small Model Large Model Number of UCU-II boards 2 3 -- 12 Peak Data Rate per Cell 3.715 Mbps 11.145 Mbps Peak Data Rate per User 3.715 Mbps 7.6 Mbps Maximum Number of HS-SCCH per Cell 8 8 Maximum Number of HS-PDSCH per Cel 8 12 Maximum Number of HSDPA users per Cell 8 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



• 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.

4.3.4.3.3 Number of HSDPA Users Supported 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.



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. hSDSCHStartCode: this parameter states the number of the first channelization code of SF = 16 used for HSDPA. This is a cell level parameter.

2. 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. Mac-hs 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 it’s 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:

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Hardwares/Node B/03.01/Lucent_UCU II_engineering.pdf

http://ns.cingular.net/RF_ENG/Lucent Documents/Forms/AllItems.aspx?RootFolder=%2fRF%5fENG%2fLucent%20Documents%2fUMTS%2fHardwares%2fNode%20B%2f03%2e03%2fUCU%20III&View=%7bEABB106E%2d12CB%2d4913%2dABE1%2d68A3539736E8%7d

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Lucent UMTS RF Forum/Lucent UMTS Implementation Guide (from CTO Office)/Lucent 03.01 Implementation Guides/15161_Cw_Lu_HSDPA Implementation Guide 1%5b1%5d.1.pdf



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 UE’s 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,



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 non-HSDPA 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.

• 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.

c. 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



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.

d. Frequency of CQI reporting: this is determined by two parameters (RNC level in Lucent):

• 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):

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



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

Quantized amplitude ratios for

⎟⎠⎞

⎜⎝⎛ Δ −

2010DPCCHHS

DPCCHHS−Δ : HS-DPCCH power offset in dB relative to DPCCH power

8 30/15 6.0 7 24/15 4.1 6 19/15 2.1 5 15/15 0.0 4 12/15 -1.9 3 9/15 -4.4 2 8/15 -5.5 1 6/15 -8.0 0 5/15 -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 HS-DPCCH 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 MAC-hs PDU over the air interface by the HARQ protocol. A timer called “hsdpa discard timer” is introduced to

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes/Customer_UMTS_RF_TAN_U03.01_HSDPA.pdf



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.

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:

MAC-hs

MAC – Control

Associated Uplink Signalling HS-DPCCH

To MAC-d

Associated Downlink Signalling HS-SCCH

HS-DSCH

HARQ

Reordering Reordering

Re-ordering queue distribution

Disassembly Disassembly



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 RNC allows HSDPA: parameter “hSDPAActivation” = TRUE

o Cell support HSDPA: parameter “cellResource.hsdpaCapable” = TRUE.

• RAB established rate > = minimum DL Rate for HSDPA defined by parameter “minRateForHSDSCH” (default: 33 kbps)



• 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).



Similarly, DCH HS-DSCH transition has a timer called “dCHHSDSCHCommitLatencyTimer”, defaulted at 650 ms.

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.



Reporting event 1D

Measurement quantity

Time

CPICH 2

CPICH 1

CPICH3

Hysteresis

Time to trigger

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:

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.



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.



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 DCH change will occur when mobilityTimer goes above 1 * 9.9 = 9.9 seconds.

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



Tim

er v

alue

timer

incr

emen

t of

HSD

PA_m

obili

ty_t

hres

hold

sec

onds

Figure 86 Mobility Scenario 2

4.3.4.8 Engineering Guidelines for HSDPA Related UTRAN Parameters

4.3.4.8.1 Summary table

4.3.4.8.1.1 HSDPA Configuration Parameters



LRNC hsDPAActivation TRUE True/False The HSDPA feature can be turned on or off at the RNC level by this parameter

LNodeB hsdpaRecourceAllocationScheme 0

small model large model

This parameter allows choosing the Node B configuration. Per default the small model is selected.

Lcell: HSDPA hSPCSCHSCCHpower 42 [dBm]

0.0 to 50.0 (in 0.1 dB

steps)

Maximal transmit power for all HSDPA channels

Lcell: HSDPA hsDSCHStartCode 12 1 to 15 Number of the first SF=16

code used for HSDPA Lcell:

HSDPA numberOfHSDSCHcode 4 1 to 12 Number of SF=16 codes reserved for HS-DSCH

Lcell: HSDPA hSCCHcode {3, 8, 9, 10} 0 to 127 Number of SF=128 codes

reserved for HS-SCCH

Lcell: HSDPA maxHsdpaUsersPerCell 24 0 to 32

Maximal number of HSDPA users per cell. There is an interaction with the Node B Configuaration.

LRNC hSDPAMeasurementPowerOffset 6 [dB]

{-6, -5.5,…,13}

dB

This parameter sets the measurement offset used in the terminal.



Table 27: HSDPA Configuration Parameters

4.3.4.8.1.2 MAC-hs Parameters



LRNC hSDPADiscardTimer 0 [ms]

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

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]

10; 20; 30; 40; 50; 60; 70; 80; 90; 100; 120; 140; 160; 200;

300 ; 400

Expiration time when outstanding MAC-hs PDUs are discarded in the terminal.

LRNC hSDPAMacHsWindowSize

32 [Number of MAC-hs 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



Lcell: ULDPCHInfo hSDPAACKpowerOffset 6 Power offset of ACKs relative to the

UL DPCCH power. Lcell:

ULDPCHInfo hSDPANACKpowerOffset 6 Power offset of NACKs relative to

the UL DPCCH power. Lcell:

ULDPCHInfo hSDPACQIpowerOffset 6 Power offset of CQI values relative to the UL DPCCH power.

LRNC hSDPAACKNACKRepetition Factor 1

Repetition factor of ACKs and NACKs. Per default the ACK/NACK is not repeated. In 03.01 only the default selection is supported.

LRNC hSDPACQIFeedbackCycleK 2 [ms]

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 hsDPACQIRepetitionFactor 1

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



Lcell: HSDPA

hSDPASrvCellChgCrit.hysteresis 3 [dB]

Hysteresis value for triggering the change of the best cell within the active set

Lcell: HSDPA

hSDPASrvCellChgCrit.timeTo Trigger 640 [ms] Time to trigger before a event 1D is

sent

Lcell: HSDPA

hSDPASvrCellChgCrit.useCIO TRUE

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 srvHSDSCHCellChgCommitLatencyTime 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.

LRNC minTimeStopSchedSrvHSDSCHCellChg 10 [10ms]

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.

LRNC srvHSDSCHCellChgeGuardTime 10000 [ms]

Guard time for serving cell change procedure

Table 30: HSDPA Serving Cell Change Parameters

4.3.4.8.1.5 Mobility Parameters



LRNC hSDPAMobilityThreshold 1 [seconds]

A mobility timer tracks the number of serving cell changes. If the timer exceeds a threshold the HS-DSCH is reconfigured to DCH.

LRNC hSDPAMobilityMaxFactor 10 Upper limit for the mobility timer

LRNC hSDPAMobilityDCHFactor 9.9 Hysteresis to switch from PS over HS-DCH to PS over DCH in case of high mobility.



Table 31: HSDPA Mobility Parameters

4.3.4.8.1.6 Call Set Up and State Transition Parameters


Recommended

Setting Range Short Description

LRNC minRateForHSDSCH 33 [kbps] 0 to 1000 [kbps]

If the core network requests a data rate below this threshold, the call is automatically set up at DCH

LRNC initialHsdpaUplinkRateRABEstablish 128 [kbps]

pSDATARATE3_64 pSDATARATE3_128

Maximal UL data rate at initial RAB establishment

LRNC dCHHSDSCHCommitLatencyTimer 65 [10 ms]

At this time the Node B commits and the UE activates the new radio bearer during DCH to HS-DSCH radio bearer reconfiguration

LRNC hSDSCHDCHCommitLatencyTimer 65 [10 ms]

At this time the Node B commits and the UE activates the new radio bearer during HS-DSCH to DCH radio bearer reconfiguration

LRNC dCHHSDSCHRLCChange TRUE

If this parameter is set to true, the RLC configuration is changed during DCH to HS-DSCH radio bearer reconfiguration

LRNC tDCHHSDSCH 3000 [ms]

Guard time for DCH to HS-DSCH radio bearer reconfiguration

LRNC dCHToHSDSCHReconfigurationProcedureTimer

100000 [ms]

Additional guard timer for DCH to HS-DSCH radio bearer reconfiguration

LRNC hSDSCHToDCHReconfigurationProcedureTimer

100000 [ms]

Additional guard timer for HS-DSCH to DCH radio bearer reconfiguration

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


constraints on how this parameter value should be set.



Setting Tradeoff: impact when the value is set to high and low values. Engineering Recommendation: Cingular’s choice on parameter value based on latest strategy

and/or field study. Access Rules RW The parameter is read-write RO The parameter is read-only RO‐SC The parameter is writable at creation then it is read-only RW‐LO The parameter is read-write only when the object is locked RW‐PL The parameter is read-write only when parent object is locked RW‐EL The parameter is read-write only when top-level object is locked RW‐DC DC = Direct Connect (parameters are adjustable via LMT, only). LMT = Local Maintenance Terminal Access Interface


OMC The (Node B or RNC) parameter is accessible via OMC-U Most of these parameters are RNC CLI accessible only. For these parameters, the general recommendation is not to change them from Cingular default until further notice from HQ. It is believed that such parameters have been optimized using advanced simulation and work well in normal traffic conditions. Further monitoring of network performance and trials will be run to study these parameters. Notification will be issued to the audience of this field guide for any updated value. This section is intended to provide guidance on OMC accessible parameters and RNC CLI parameter that are most relevant to network performance and customer experience. For all the other “less critical” RNC CLI accessible only parameters, refer to parameter excelsheet in section 7.1, this field guide and Lucent Load Control TAN. It is strongly recommended not to modify the CLI only parameters as these are sensitive parameters with high impact on performance. For OMC accessible parameters, current recommendations should be followed and alternation should be coordinated by HQ and Regional leads. HSDPA Configuration Parameters Hsdpa capable

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



Dependencies and constraints: Setting Tradeoff: Engineering Recommendation: True

Hsdpa Activation

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

HSCCH Code

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.

HSDPA Measurement Offset

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

HSDPA Resource Allocation Scheme

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.

HSDPA Start Code



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

HS‐PDSCH and HSCCH Total Power

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

Initial HSDPA Uplink Rate RAB Establishment

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

Maximum Number of HSDPA Users Per Cell Parameter Name in database: maxHsdpaUsersPerCell Access in OMC GUI: LCell HSDPA tab OMC RW Unit & Range: {0…32} 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

Number of HS DSCH Codes

Parameter Name in database: numberOfHSDSCHcode Access in OMC GUI: LCell HSDPA tab OMC RW Unit & Range: {1,...,12} Granularity: per cell



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

MAC‐hs Parameters HSDPA ACk/NACK Repetition Factor

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

HSDPA CQI Feedback Cycle

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

HSDPA CQI Repetition Factor

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

HSDPA discard Timer

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:



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.

HSDPA Mac‐Hs Window Size

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

HSDPA T1 Timer

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



Physical Layer Parameters HSDPA ACK Power Offset

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)

HSDPA CPQ Power Offset

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)

HSDPA NACK Power Offset

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 HSDPA Serving Cell Change Hysteresis

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



HSDPA Serving Cell Change Time To Trigger

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

HSDPA Serving Cell Change CIO

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)

HSDPA Serving Cell Change Use CIO

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

Minimum Time to Stop Schedule Data to Serving Cell during Cell Change

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)

Serving Cell Change Commit Time

Parameter Name in database: srvHSDSCHCellChgCommitLatencyTime Access in OMC GUI: CLI only. RNC CLI RW Unit & Range: {0,… 255} unit 10ms. Granularity: per RNC



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)

Serving Cell Change Guard Time

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 HSDPA Mobility DCH Factor

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

HSDPA Mobility Maximum Factor

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

HSDPA Mobility Maximum Factor

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.



Setting Tradeoff: Engineering Recommendation: 9.9 seconds

State Transition Parameters

Minimum DL Rate for HSDSCH

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

DCH to HSDSCH Change Commit Latency Timer

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)

DCH to HSDSCH Reconfiguration Procedure Timer

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

HSDSCH to DCH Change Commit Latency Timer

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)

HSDSCH to DCH Reconfiguration Procedure Timer

Parameter Name in database: hSDSCHToDCHReconfigurationProcedureTimer



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

DCH HSDSCH transition timer

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



4.3.5 Inter-Technology Handovers (IRAT)

4.3.5.1 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 mobile-assisted 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 Cingular’s 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_Inter-RAT_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).

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes/Customer_UMTS_RF_TAN_U03.01_Inter-RAT_Handover_UMTS-GSM.pdf




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 RAT-Handover 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.



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 UE’s 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 it’s 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.



Figure 87. Inter System HO



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 it’s connected to the threshold for a particular event like in the formulas below. In other words with this parameter it’s possible to prevent unnecessary reporting due to the regular signal fluctuations. Measurement reporting activation (2D) Triggering condition - needed to trigger an event.

2/22 ddUsedUsed HTQ −≤

Qused: current measurement of CPICH Ec/Io (RSCP will be supported in future release) defined below:

QUTRAN is the estimated quality of the active set on the used frequency MUTRAN is the estimated quality of the active set on the used frequency Mi is a measurement result of cell i in the active set the used frequency NA is the number of cells in the active set on the used frequency MBest is the measurement result of the cell in the active set with the highest measurement result W 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)

Measurement Quality UMTS

Time

CPICH#1

MR 2d

MR 3a

UMTS CM GSM

MR 2f

E2d threshold

Measurement Quality GSM

Time to trigger

E3a UMTS treshold

E2f threshold E3a GSM threshold

TTT UMTS No CM UMTS No

CM UMTS CM

MR 2d

2/22 ddUsedUsed HTQ −≤

2/22 ffUsedUsed HTQ +≥⎩⎨⎧

+≥−≤

2/2/

3

3

aGSMGSM

aUsedUsed

HTMHTQ

TTT TTT

Best

N

iiUTRANUTRAN LogMWMLogWLogMQ

A

⋅⋅−+⎟⎟⎠

⎞⎜⎜⎝

⎛⋅⋅=⋅= ∑

=

10)1(10101



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



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.

2/22 ddUsedUsed HTQ +>

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

2/22 ffUsedUsed HTQ +≥



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:

2/3 aUsedUsed HTQ −≤

For coverage estimation of GSM network:

2/3aRATOtherRATOtherRATOther HTCIOM +≥+

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.



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)

parameter name parameter name in database

range Cingular Default

description



Activate CM for IRAT Lcell::Inter‐SystemHO::compressedModeInterRat

True / False TRUE

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.

Border Cell to GSM Lcell::borderCellToGsm True / False TRUE Marks a cell as a border cell of the UMTS network to a GSM network.

BSIC Verification LRNC::GSMextTable::bsicVerificationRequired

True / False TRUE

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.

combined gsm neighbor list size

LRNC::umts2GsmHOMeas.combinedGsmNeighbourListSize

1…..32 in step of 1 20

This parameter defines the maximum number of GSM neighbour cells related to the active set, which should be measured by the UE

GSM to UMTS Handover

LRNC::GSMExtTable::gsmToUmtsHandover

True / False FALSE The parameter enables/disables the GSM to UMTS handover feature on a per cell basis.

gsmQualityThreshold (gsmThresh3a)

LRNC::umts2GsmHOMeas.gsmQualityThreshold

‐115 ... 0 dBm ‐98 Threshold for 3a (HO execution)

Handover Relocation Guard Timer

hoRelocGuardTimer 5‐ 60 seconds in step of 1 10

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.



InterRAT filtercoefficient

LRNC::uMTS2GSMHOmeas.gsmfiltercoefficient

coeff_0, coeff_1, …., coeff_9, coeff_11, coeff_13, coeff_15, coeff_17, coeff_19

coeff_3

Defines a low pass filter for the GSM measurements. Used for measurements for event 3A and event 3C.

iuReleaseCoordinationTimer

LRNC:timers1:iuReleaseCoordinationTimer

1 – 100 seconds 20

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.

MAHO GSM Measurements

Lcell::mahoByGsmMeasurements

True / False TRUE

This parameter enables/disables the mobile‐assisted handover algorithm (MAHO) for triggering the UMTS to GSM handover procedure.

OutGSMAdjCells reference cell

OutGSMAdjCells.refCell name of the neighbor cell per design distinguish name of the cell

OutGSMAdjCells enable Broadcast

OutGSMAdjCells.enableBroadcast

True / False TRUE

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.

OutGSMAdjCells enable MAHO

OutGSMAdjCells.enableMAHO

True / False TRUE

Defines whether the GSM neighbour cell should be used as

target for UMTS to GSM handover with MAHO algorithm.

Relocation Preparation Timer

LRNC:timers1:tRelocPrep

1 – 20 seconds 5

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.



TRelocOverall LRNC:timers1:tRelocOverAll

1 – 20 seconds 5

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.

umts to Gsm handover

LRNC::umtsToGsmHandover

True / False TRUE The parameter enables/disables the UMTS to GSM handover feature per RNC

umts2GsmQActCM2D.threshold (usedFreqThresh2dEcno)

Lcell::umts2GsmQActCM2D.threshold

‐24 ... 0 dB ‐13 Ec/No threshold for trigger event 2d for CM activation

umts2GsmQActCM2D.timeToTrigger

Lcell::umts2GsmQActCM2D.timetotrigger

0,10,20,40,60,80,100,120,160,200,240,320,640,1280,2560,5000

ms

320

Specifies the time for which the triggering condition must be true before the UE sends an event triggered measurement report to the UTRAN

umts2GsmQDeactCM2F.threshold (usedFreqRelThresh2fEcno)

Lcell::umts2GsmQDeactCM2F.threshold

‐24 ... 0 ‐11 Ec/No threshold for trigger event 2f for CM deactivation

umts2GsmQDeactCM2F.timeToTrigger

Lcell::umts2GsmQDeactCM2F.timetotrigger

0,10,20,40,60,80,100,120,160,200,240,320,640,1280,2560,5000

ms

640

Specifies the time for which the triggering condition must be true before the UE sends an event triggered measurement report to the UTRAN

umts2GsmQTriggerMAHO.threshold (utranThresh3aEcno)

Lcell::umts2GsmQTriggerMAHO.threshold

‐24 ... 0 dB ‐13 Ec/No threshold for HO trigger

umts2GsmQTriggerMAHO.timeToTrigger

Lcell::umts2GsmQTriggerMAHO.timetotrigger

0,10,20,40,60,80,100,120,160,200,240,320,640,1280,2560,5000

ms

0

Specifies the time for which the triggering condition must be true before the UE sends an event triggered measurement report to the UTRAN.

Weighting (3a) LCell::umts2GsmQTriggerMAHO.weight

0.0 up to 2.0 step size=0.1 1

Specifies weighting between the strongest link and remaining active links for computing the quality of the UMTS system.



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



and/or field study.

Activate CM for IRAT

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

Border Cell to GSM 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.

BSIC Verification

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.



combined gsm neighbor list size

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

GSM to UMTS Handover

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)

Gsm Quality Threshold (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.

Handover Relocation Guard Timer

Parameter Name in database:hoRelocGuardTime Access in OMC GUI: LRNC handover tabl handover table section OMC_RW Unit & Range: 5 – 60 seconds Granularity: RNC level



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

InterRAT filter coefficient

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.

Iu Release Coordination Timer

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



MAHO GSM Measurements

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)

OutGSMAdjCells reference cell

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

OutGSMAdjCells enable Broadcast

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)

OutGSMAdjCells enable MAHO

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)

Relocation Preparation Timer Parameter Name in database: tRelocPrep 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 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 . OMC-RW 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.



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 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 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 . 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: 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 . OMC-RW 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.



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 . 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: 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 (e3a threshold)

Parameter Name in database: umts2GsmQTriggerMAHO.threshold Access in OMC GUI: LCell Inter-system handover tab umts2GsmQTriggerMAHO section . OMC-RW Unit & Range: ‐24 ... 0 dB 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 (e3a time to trigger)

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



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)

http://ns.cingular.net/RF_ENG/docs_nokia.aspx?RootFolder=%2fRF%5fENG%2fNokia%20Documents%2fIRAT&View=%7b7577082B%2dF065%2d40E9%2dBC23%2d898BC000FE7C%7d

http://ns.cingular.net/Network Documents/ND-00015.pdf

http://ns.cingular.net/RF_ENG/Siemens/GSM/Field Guides/ND-00126.pdf



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 Lucent’s 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 Lucent’s Orthogonal Channel Noise Simulator (OCNS) for 03.01. OCNS is used to simulate downlink traffic load within a cell or cluster of cells. Lucent’s 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.

http://infoweb.edc.cingular.net/umts/documents.jsp?mId=12538891&fId=12539015

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes



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

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Lucent UMTS RF Forum/Lucent UMTS Field Guide/LU-0301-UTRAN-Parameters-v3.3.xls



8. Test Results This section will contain summaries, and links to the Lab, FOA, SOA, and Parameter specific-testing results.

8.1 FOA Test Results

8.1.1 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 Parameter Field Trial Results

8.2.1 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.

http://ns.cingular.net/RF_ENG/Lucent Documents/Forms/AllItems.aspx?RootFolder=%2fRF%5fENG%2fLucent%20Documents%2fLucent%20UMTS%20Field%20Guide%2f03%2e01%20FOA%20Results&View=%7bEABB106E%2d12CB%2d4913%2dABE1%2d68A3539736E8%7d

http://ns.cingular.net/RF_ENG/docs_lucent.aspx?RootFolder=%2fRF%5fENG%2fLucent%20Documents%2fUMTS%2fFOA%20and%20Trials%2fFOA%20%2d%2003%2e01%2f03%2e01%20P0%20Test%20Results&View=%7b2FA93BC3%2d7E67%2d4C9C%2d9661%2d8BDF27A8B126%7d

http://ns.cingular.net/RF_ENG/docs_lucent.aspx?RootFolder=%2fRF%5fENG%2fLucent%20Documents%2fUMTS%2fFOA%20and%20Trials%2fFOA%20%2d%2003%2e01%2f03%2e01%20P1%20lite%20Test%20Results&View=%7b2FA93BC3%2d7E67%2d4C9C%2d9661%2d8BDF27A8B126%7d

http://ns.cingular.net/RF_ENG/Lucent Documents/Forms/AllItems.aspx?RootFolder=%2fRF%5fENG%2fLucent%20Documents%2fLucent%20UMTS%20Field%20Guide%2fParameter%20Field%20Trial%20Results&View=%7bEABB106E%2d12CB%2d4913%2dABE1%2d68A3539736E8%7d

http://ns.cingular.net/RF_ENG/Lucent Documents/Forms/AllItems.aspx?RootFolder=%2fRF%5fENG%2fLucent%20Documents%2fLucent%20UMTS%20Field%20Guide%2fParameter%20Field%20Trial%20Results&View=%7bEABB106E%2d12CB%2d4913%2dABE1%2d68A3539736E8%7d



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)

http://ns.cingular.net/RF_ENG/docs_lucent.aspx?RootFolder=%2fRF%5fENG%2fLucent%20Documents%2fUMTS%2fLucent%20UMTS%20RF%20Forum%2fLucent%20UMTS%20Implementation%20Guide%20%28from%20CTO%20Office%29&View=%7b2FA93BC3%2d7E67%2d4C9C%2d9661%2d8BDF27A8B126%7d

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes/Customer_UMTS_RF_TAN_U03.01_Access_Procedures.pdf

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes/Customer_UMTS_RF_TAN_U03.01_Cell_Selection_Reselection.pdf

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes/Customer_UMTS_RF_TAN_U03.01_Handover.pdf


http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes/Customer_UMTS_RF_TAN_U03.01_HSDPA.pdf

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes/Customer_UMTS_RF_TAN_U03.01_Load_Control_Algorithms.pdf

http://ns.cingular.net/RF_ENG/Lucent Documents/UMTS/Features and Tools/Features and Functionalities/03.01/03.01 Translation Application Notes/Customer_UMTS_RF_TAN_U03.01_OCNS.pdf


http://books24x7.com/books.asp?imprintid=348



10.2 Index

To be added later.



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.



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_Inter-RAT_Handover_UMTS-GSM



3G UMTS UTRAN

Documents

Transcript of 3G UMTS UTRAN