GSM Systems DivisionUTRAN Optimisation GuideRNC 5000UMTS System Requirements & Architecture Group (SAR)AbstractThis document provides a description and optimisation guideline for the UTRAN RF algorithms and related configuration parameters.1Release HistoryVersion Release Date Author(s) Change History1.0 March 28, 2003UMTS System Architecture Initial release ver 1.0 for USR1.01.1 July 15, 2003 UMTS System Architecture:Darek GodynEsperanza AlonsoJulie ChenIgnacio RivasJose-Miguel TorresRelease 1.1 for USR1.0.RNC 5000 algorithms description update recommendation extensions according to RNC 5000 software load 12.0.0.8.1.2 September 30, 2003UMTS System Architecture Release 1.2 for USR1.0.RNC 5000 algorithms description update recommendation extensions according to RNC 5000 software load 12.0.0.10 and 12.0.0.11 ADD DCCCMC and SET COIFTIMER are now internal commands Name change for two parameters in "ADD CELLFRC": UlSrvrcDecisionThd -> UlPsTraffDecThs and DlSrvrcDecisionThd -> DlPsTraffDecThs Name change for one parameters in "ADD CELLRLPWR": RLMaxDlTxPower ->RLMaxDlPower1.3 December 30, 2003UMTS System Architecture:Darek GodynJulie ChenIgnacio RivasJose-Miguel TorresRelease 1.3 for USR 1.0.RNC 5000 algorithms description update recommendation extensions according to RNC 5000 software load 12.0.0.10 and 12.0.0.11 LCS Cell ID algorithm Sensitivity analysis Expexted KPI values2.0 June 30, 2004 UMTS System Architecture:Darek Godyn Esperanza AlonsoJulie ChenIgnacio RivasJose-Miguel Torres Weihung LinIke PenasAlgorithm complinat with RNC software release 13.0.0.5.02.1 September 20, 2004UMTS System Architecture: Algorithm compliant with RNC software 2Darek Godyn Ignacio RivasJose-Miguel Torres Weihung LinIke PenasWalter Featherstonerelease 13.0.0.8.0Modifications and extention of KPIs definitions.2.2 May 5,2005 UMTS System Engineering:David BhatoolaulEric VillerMike WitherellWalter FeatherstoneWeihung LinAlgorithms update with RNC software release 1.3.0.0.15.03Table of Contents1 INTRODUCTION................................................................................................... 13 1.1 OPTIMISATION SCENARIO DESCRIPTION ...................................................................... 13 1.1.1 Standard Optimisation Scenario................................................................. 13 2 RANDOM ACCESS ................................................................................................ 15 2.1 RANDOM ACCESS ALGORITHM .................................................................................. 15 2.1.1 Algorithm Overview .................................................................................... 15 2.1.2 Related Data base Parameters................................................................... 20 2.1.3 Key Performance Indicators....................................................................... 24 2.1.4 Optimization Guidelines............................................................................. 24 3 POWER CONTROL............................................................................................... 27 3.1 INTRODUCTION ........................................................................................................ 27 3.2 OPEN POWER CONTROL LOOP .................................................................................. 27 3.2.1 Downlink Open Power Control Loop......................................................... 28 3.2.2 Uplink Open Power Control Loop .............................................................. 28 3.2.3 Related Data base Parameters................................................................... 31 3.2.4 Key Performance Indicators....................................................................... 32 3.2.5 Optimization Guidelines............................................................................. 32 3.3 CLOSED POWER CONTROL LOOP............................................................................... 35 3.3.1 Downlink Closed Power Control Loop....................................................... 35 3.3.2 Uplink Closed Power Control Loop........................................................... 51 4 HANDOVER CONTROL ...................................................................................... 75 4.1 MEASUREMENT CONTROL ........................................................................................ 75 4.1.1 Algorithm Description ................................................................................ 75 4.1.2 Related Database Parameters .................................................................... 80 4.1.3 Optimisation Guidelines............................................................................. 81 4.2 SOFT / SOFTER HANDOVER ..................................................................................... 83 4.2.1 Algorithm Description............................................................................... 83 4.2.2 Related Database Parameters .................................................................... 89 4.2.3 Most Relevant Key Performance Indicators............................................... 91 4.2.4 Optimisation Guidelines............................................................................. 93 4.3 INTRA-FREQUENCY HARD HANDOVER ....................................................................... 99 4.3.1 Optimisation Guidelines............................................................................. 99 4.4 INTER-FREQUENCY HARD HANDOVER..................................................................... 101 4.4.1 Algorithm Overview .................................................................................. 101 4.4.2 Related Database Parameters .................................................................. 103 4.4.3 Most Relevant Key Performance Indicators............................................. 104 4.4.4 Optimisation Guidelines........................................................................... 105 4.5 INTER-RAT HARD HANDOVER .............................................................................. 106 4.5.1 Algorithm Overview .................................................................................. 106 4.5.2 Related Database Parameters .................................................................. 108 4.5.3 Most Relevant Key Performance Indicators............................................. 109 4.5.4 Optimisation Guidelines........................................................................... 110 4.6 COMBINED INTER-FREQUENCY & INTER-RAT HARD HANDOVER............................... 110 4.7 COMPRESSED MODE CONTROL ................................................................................ 112 4.7.1 Algorithm Overview .................................................................................. 112 44.7.2 Related Database Parameters .................................................................. 119 4.7.3 Most Relevant Key Performance Indicators............................................. 121 4.7.4 Optimisation Guidelines........................................................................... 122 4.8 PRIORITY OF DIFFERENT HANDOVER TYPES .............................................................. 125 4.9 RADIO LINK SYNCHRONISATION ASPECTS................................................................. 125 4.9.1 Algorithm Overview .................................................................................. 125 4.9.2 Related Database Parameters .................................................................. 125 4.9.3 Optimisation Guidelines........................................................................... 126 4.10 LAYERED CELL TRAFFIC ABSORPTION................................................................... 127 4.10.1 Algorithm Overview ................................................................................ 127 4.10.2 Related Database Parameters ................................................................ 129 4.10.3 Most Relevant Key Performance Indicators........................................... 131 4.10.4 Optimisation Guidelines......................................................................... 131 5 DYNAMIC CHANNEL CONFIGURATION CONTROL............................... 133 5.1 DYNAMICCHANNELCONFIGURATIONCONTROLANDUE STATESWITCHINGALGORITHMS 133 5.1.1 Algorithm control switches....................................................................... 135 5.1.2 Detailed Description................................................................................. 135 5.1.3 RRC state switching algorithm................................................................. 143 5.1.4 Related Data base Parameters................................................................. 145 5.1.5 Key Performance Indicators..................................................................... 152 5.1.6 Optimization Guidelines........................................................................... 153 6 AMR RATE CONTROL OVER AIR INTERFACE......................................... 162 6.1 AMR RATE CONTROL NORMAL OPERATION (NO TFO) .......................................... 162 6.1.1 Algorithm Overview .................................................................................. 162 6.1.2 Related Data base Parameters................................................................. 166 6.1.3 Key Performance Indicators..................................................................... 177 6.1.4 Optimization Guidelines........................................................................... 179 7 RAB RECONFIGURATION AND RAB/RB MAPPING................................. 187 7.1 RAB TO RB MAPPING ALGORITHM....................................................................... 187 7.1.1 Algorithm Overview .................................................................................. 187 7.1.2 Related Data base Parameters................................................................. 203 7.1.3 Key Performance Indicators..................................................................... 207 7.1.4 Optimization Guidelines........................................................................... 208 8 RADIO ADMISSION CONTROL ...................................................................... 218 8.1 MEASUREMENT BASED CALL ADMISSION CONTROL ALGORITHM................................. 218 8.1.1 Algorithm Overview .................................................................................. 218 8.1.2 Trigger of Admission Request................................................................... 219 8.1.3 Calculation of Load Factor ...................................................................... 222 8.1.4 Background Noise..................................................................................... 228 8.1.5 BLER vs. Eb/No Curves ............................................................................ 228 8.1.6 Activity Factor .......................................................................................... 228 8.1.7 Cell Environment Type............................................................................. 229 8.2 EQUIVALENT NUMBER OF USER CALL ADMISSION CONTROL ALGORITHM..................... 229 8.2.1 Uplink Load Factor................................................................................... 230 8.2.2 Downlink Load Factor .............................................................................. 230 8.3 RELATED DATA BASE PARAMETERS......................................................................... 231 58.3.1 Key Performance Indicators..................................................................... 236 8.3.2 Optimization Guidelines........................................................................... 237 9 CONGESTION CONTROL................................................................................. 241 9.1 ALGORITHM OVERVIEW......................................................................................... 241 9.1.1 Node B Measurements (Event-triggered or Periodic) .............................. 242 9.1.2 Algorithm Implementation ........................................................................ 244 9.2 RELATED DB PARAMETERS .................................................................................... 246 9.3 KEY PERFORMANCE INDICATORS............................................................................. 248 9.4 OPTIMISATION GUIDELINES..................................................................................... 248 10 CELL SELECTION / RE-SELECTION .......................................................... 250 10.1 ALGORITHM OVERVIEW....................................................................................... 250 10.1.1 Cell Selection Procedure ........................................................................ 250 10.1.2 UE Measurements................................................................................... 251 10.1.3 Cell Reselection Procedure in Idle Mode............................................... 252 10.1.4 Cell Reselection in RRC Connected Mode .............................................. 254 10.2 RELATED DB PARAMETERS .................................................................................. 255 10.3 KEY PERFORMANCE INDICATORS........................................................................... 256 10.4 OPTIMISATION GUIDELINES................................................................................... 258 11 POTENTIAL USER CONTROL....................................................................... 262 11.1 ALGORITHM OVERVIEW....................................................................................... 262 11.2 RELATED DATA BASE PARAMETERS....................................................................... 264 11.3 KEY PERFORMANCE INDICATORS........................................................................... 267 11.4 OPTIMIZATION GUIDELINES................................................................................... 269 11.4.1 Parameters and Recommendation .......................................................... 269 11.5 EXPECTED KPI VALUE....................................................................................... 269 11.6 SENSITIVITY ANALYSIS ........................................................................................ 270 12 CELL BREATHING........................................................................................... 271 12.1 ALGORITHM OVERVIEW....................................................................................... 271 12.2 RELATED DATA BASE PARAMETERS....................................................................... 272 12.3 KEY PERFORMANCE INDICATORS........................................................................... 274 12.4 OPTIMIZATION GUIDELINES................................................................................... 276 12.4.1 Parameters and Recommendation .......................................................... 276 12.4.2 Expected KPI Value ................................................................................ 278 12.4.3 Sensitivity Analysis .................................................................................. 279 13 INTER-CARRIER LOAD BALANCING ........................................................ 280 13.1 ALGORITHM OVERVIEW....................................................................................... 280 13.1.1 Node B Periodic Measurements .............................................................. 281 13.1.2 Algorithm Implementation ...................................................................... 281 13.2 RELATED DB PARAMETERS .................................................................................. 283 13.3 KEY PERFORMANCE INDICATORS........................................................................... 284 13.4 OPTIMISATION GUIDELINES................................................................................... 285 14 LOCATION SERVICES .................................................................................... 286 14.1 CELL ID POSITIONING METHOD........................................................................... 286 14.1.1 Related Data base Parameters............................................................... 288 14.1.2 Key Performance Indicators................................................................... 290 614.1.3 Optimization Guidelines......................................................................... 290 14.2 ASSISTED GPS POSITIONING METHOD................................................................... 292 14.2.1 Related Data base Parameters............................................................... 295 14.2.2 Key Performance Indicators................................................................... 301 14.2.3 Optimization Guidelines......................................................................... 301 15 DIRECT RETRY DECISION ............................................................................ 303 15.1 ALGORITHM OVERVIEW....................................................................................... 303 15.1.1 4.2 RRC Retry Decision procedure......................................................... 304 TheRRCconnectionestablishment process is performedthroughseveralmessages as indicated in Figures below. .......................................................... 304 15.1.2 4.3 Redirection procedure ...................................................................... 306 15.2 RELATED DATA BASE PARAMETERS....................................................................... 307 15.3 KEY PERFORMANCE INDICATORS........................................................................... 308 15.4 OPTIMIZATION GUIDELINES................................................................................... 308 15.4.1 Parameters and Recommendation .......................................................... 308 16 ATM CAC (CONNECTION ADMISSION CONTROL)............................... 310 16.1 ALGORITHM OVERVIEW....................................................................................... 310 16.1.1 Algorithm for dynamic ATM connections............................................... 310 16.2 RELATED DATA BASE PARAMETERS....................................................................... 313 16.3 KEY PERFORMANCE INDICATORS........................................................................... 313 16.4 OPTIMIZATION GUIDELINES................................................................................... 314 16.4.1 Parameters and Recommendation .......................................................... 314 17 SRNS RELOCATION ........................................................................................ 316 17.1 ALGORITHM OVERVIEW....................................................................................... 316 17.1.1 Relocation Triggered by Iur Delay......................................................... 317 17.1.2 Relocation Triggered by Iur Traffic Occupancy..................................... 317 17.2 RELATED DB PARAMETERS .................................................................................. 317 17.3 KEY PERFORMANCE INDICATORS........................................................................... 319 17.4 OPTIMISATION GUIDELINES................................................................................... 320 7REFERENCES:20.011-340 Service accessibility23.003 Numbering, Addressing and Identification25.133-360 Requirements for Support of Radio Resource Management (FDD)25.211-360 Physical channels and mapping of transport channels onto physical channels (FDD)25.214-360 Physical layer procedures (FDD)25.215-360 Physical layer; Measurements (FDD)25.304-360 UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected Mode25.331-370 RRC Protocol Specification25.401-360 UTRAN Overall Description25.413-360 UTRAN Iu interface RANAP signalling[SEA2-RRM01] Description of the Taurus v1.2 Soft Handover Algorithm, S. Barrett and E. Villier, June 03.SEA1-C-Feb2 Simulation analysis of the DCCC and Transport Channel switching algorithm v1.0 (9/15/03)[SEA2-SHO3] Soft Handover Results for USR1 Optimisation Guide, E. Villier, June03.Taurus v1.2 with CRs Soft Handover Algorithm Simulation Results, E. Villier, June 03.Comparison of Simulation Results of Soft Handover Algorithms for Taurus, E. Villier, June 03.[SEA2-SHO4] Simulation Results for Taurus Soft Handover Algorithm2, E. Villier, Aug 03.[SEA2-SHO9] Sensitivity Analysis of the Taurus Soft Handover Algorithm2, E. Villier, Nov 03.Simulation Results for Sensitivity Analysis of the Taurus Soft Handover Algorithm2, E. Villier, Nov 03.[SEA2-RRM02] SHO Algorithm1 Description v2, E. Villier, Li Zhen, June 03.[SEA2-RRM03] SHO Algorithm2 Description v1.4, E. Villier, Li Zhen, July 03.[SEA2-SHO4] Simulation Results for Taurus Soft Handover Algorithm2, E. Villier, Aug 03.[SEA02-PC] Simulations on the Taurus V1.2 UL OLPC algorithm for the optimisation guide. Asoka Korale Aug/03.[QoS38-F1] Description of the Huawei Inter-RAT Hard Handover Algorithm, S. Benes, June 03.HM_RRM_AD_02 Descriptionof theTaurus ULOuter LoopPower Control Algorithm v.5.1 Asoka Korale Jul 03.[QoS38-E2][QoS38-F2]Combined Inter-RAT HHO Compressed Mode Parameters, L. Downing, S. Benes, June 03.[HM_RRM_AD_02] Description of the Taurus UL Outer Loop Power Control Algorithm, A. Korale, June 11.[HM_RRM_AD_11] DPB Algorithm Description for Huawei ver1.0 Fu Yusun[EDE-SW-99-242-D] Europa Programming Model and Host ICD, Ian Wylie, 8Graham Johnson, Jun 01.[HM_RRM_SR_02] Simulation of the Taurus V1.2 Outer Loop Power Control Algorithm, A. Korale, May 03.[SEA/RAN/03/032] Outer-Loop Power Control Taurus v1.2 Simulation, E. Villier, June 03.[SEA/RAN/03/095] Outer-Loop Power Control Taurus v1.2 Simulation, A. Korale, Nov 03.[SEA/RAN/04/095] Simulation results on the v1.3 OLPC algorithm with respect to data mode BER target parameter, low BLER service and multi-RAB for the optimisation guide, Asoka Korale[HM_RRM_AD_02a] Taurus v1.3 UL Outer Loop Power Control (ver 8.0), Asoka Korale, Eric Villier, 04/27/2004[SEA/RAN/04/014]Simulation and analysis oftheTaurus v1.2Downlink power balancing algorithm for the optimisation guide, Asoka Korale, 4/30/2004Planning Guide http://compass.xx.com/go/98866920DV&V RNC configuration Databasehttp://www.cig.xx.com/~adg003/rnc5000conf.html [QoS38-Task7a] Recommended Compressed Mode Patterns for Inter-RAT Hard Handover, S. Benes,D. Schaeffer and L. Downing, June 04[SEA/RAN/04/019] RACH Sensitivity Analysis, Eric Villier, SEA-2, June 20049GlossaryAAL2 ATM adaptation layer 2AAL5 ATM adaptation layer 5AC Access ClassAICH Acquisition Indicator ChannelAMRC AMR Rate ControlARFCN Absolute Radio Frequency Channel NumberASC Access Service ClassBCCH Broadcast Control ChannelBCH Broadcast ChannelBER Bit error rateCAC Congestion Admission Control10CCPCH Common Control Physical ChannelCM Compress ModeCMCF Compress Mode ConfigurationCPICH Common Pilot ChannelDCH Dedicated ChannelDPCCH Dedicated Physical Control ChannelDPDCH Dedicated Physical Data ChannelEc/No The ratioof received chip energy(Ec) tothe power spectral density of the noise (No).FER Frame Error RateFRC Fundamental Resource ConfigurationLCC Load Congestion ControlLDB Load BalancingLDM Load MonitoringLMT Local Maintenance TerminalMAC Medium Access ControlMLP Mac Logical PriorityMM Mobility ManagementNAS Non Access StratumNBAP Node B Application PartNIB Network Interface BoardOMC Operation and Maintenance CentreOVSF Orthogonal Variable Spread FactorPLMN Public land mobile networkPMM Packet Mobility ManagementPRACHPhysical Random Access ChannelQoSQuality Of ServiceRACHRandom Access ChannelRLC Radio Link ControlRNC Radio Network ControllerRRC Radio Resource ControlRSCP Received Signal Code Power after dispreadingRSSI Received Signal Strength IndicatorSF Spreading FactorSFER Service Frame Error RateSIB System Information BroadcastSIR Signal to Interference RatioSR Spacing RateSTTD Space Time Transmission DiversityTFCI Transport Format Combination IndicatorTFS Transport Format SetTGPS Transmission Gap Pattern SequenceTPC Transmit Power ControlTSTD Time Switched Transmission DiversityTTI Time Transmission IntervalUE User EquipmentUTRAN UMTS Terrestrial Radio Access NetworkVC Virtual Circuit11VP Virtual Path121 IntroductionThis document provides informationtooptimisetheUTRANsystemthroughthe modification of RF related parameters. Every optimisation area covers the following information:Optimized DB parameters: The most relevant DB parameters in the context of given algorithm / feature.Key Performance Indicators (KPI): are estimators that drive the optimisation process that result in the increase of UTRAN performance. The high UTRAN performance is obtained when we simultaneously observe: Low transmission Block Error Rate (BLER) Low transmission delay High number of service satisfied users High system coverage area Low drop call rateOptimisationGuidelines:Theguidelines are to provide recommended value to the main system configurable parameters that set the behaviour of a given algorithm / feature.Guideline are given in terms of (i) DB parameter impact on KPIs, (ii) interaction with other features and (iii) abnormal situations, as applicable.1.1 Optimisation Scenario DescriptionIt is clear that different system parameters should be set up under a different radio, trafficandloadconditions. Astandardscenariohasbeendefinedinthefollowing sections as a baseline for the optimisation and system simulation. Unless otherwise specified, thedatabaseparameter recommendations andtheUTRANPerformance measures (KPIs) provided in this document are based on this particular scenario.1.1.1 Standard Optimisation ScenarioA) RF CONDITIONS3GPP Typical Urban RF Environment with a UE speed of 3 km/h (TU3) is chosen for the standard scenario. The channel model is defined in 3GPP TS 25.943.B) TRAFFIC MIX.Typical trafficprofilesaredefinedintheUnifiedSimpleTrafficModel (USTM). However, certain simplifications have been taken due to limitations on system simulators when translating the USTM services to supported user categories. In the standard scenario, the following traffic mix is considered per profile: 80% of AMR voice users at 12.2 Kbps 20% of data traffico FTP 64 kbps13o FTP 144 kbpso FTP 384 kbpsVoice users have an activity factor of 0.5 and they are continuously active (infinite session duration)FTP users download a file of 48 Kbytes of size, every 43.2 seconds.C) NETWORK LOADNetwork load refers to cell loading from the point of view of CDMA noise rise in the uplink and carrier power in the downlink. For system simulations, SATURN is used to obtain the number of voice users and data users (for each service) in the network in order to produce the desired load.The following load scenarios are considered: Load: 10 % Load: 50 % The load factors are related with noise rise defined as ratio:NINTPPNR ,where:INTP - is total received wideband power,NP - is the power of wideband thermal noise,then load factor equals:

,_

10] [10 1dB NRLoad[%],The relation between system load factor and noise rise is illustrated on the following chartD) SERVICE TO RAB MAPPINGUTRAN assigns a radio bearer to each user according to the service type and QoS requested. The following mapping of services to RBs has been considered, Voice users: AMR rate at 12.2 Kbps FTP64: DCH at 64 kbps FTP144: DCH at 144 kbps FTP384: DCH at 384 kbps140%10%20%30%40%50%60%70%80%0 1 2 3 4 5 6Noise Rise NR [dB]Load [%]2 Random Access2.1 Random Access AlgorithmWhenever UE needs to access network service and initate uplink transmittion it must execute the random access procedure using UL common transport channel.Therandom-accesstransmission isbased onaSlotted ALOHAapproachwithfast acquisition indication carried through AICH DL channel. The procedure consists of transmission at randomly selected moment of the time, one or more preambles in the available uplinkaccess slots until networkgrants access tochannel for sending message part. The open power control loop is used for that message part transmission.The following subsections provide concept overview of the physical transport main and it describes the most relevant aspects regarding the UE RACH access procedure. The random access procedure takes place in RLC/MAC and PHY layers of the UE and is controlled by UTRAN through RRC signalling. UTRANcanprioritisethePRACHusagebyassigningtheAccessServiceClasses (ASCs) to UEs requesting for service access. This is done through different PRACH resources allocation i.e. channel and scrambling codes, UL slots and random access probabilities assessment for each ASC. There are 8 possible Access Service Classes numbered form 0 to 7.UTRAN selects the ASC within the allowed ASC set based on OMC provisioned AccessServiceClass parameter value. It is allowedthat morethanoneASCis assignedtothesame PRACH resource.2.1.1 Algorithm Overview2.1.1.1 PRACH Transmission ResourcesThe PRACH transmission structure consists of one or several preambles and a message part. The preamble channelization code of length 16 is generated based on the allocated preamble signature, which also depends on Access Service Classes i value assignment. For a given Access Class the use of preamble signatures is limited by range given by provisionable parameters AvailablesignatureStartIndex and AvailablesignatureEndIndex.(Issue: What is algorithm preamble signature selection for given ASC?)ThePRACHresourcesconsist ofaccesstimeslotsandpreamblesignatures. Those resources are classified into several access service classes (ASC) to ensure providing random access with different priorities. One or all ASCs might be allocated to the same access timeslots or preamble signatures. The ASC defines the partition of certain PRACH resources with associated (access probability) PiThe ASC is numbered within the range from 0 to 7. The ASC=0 has highest priority and ASC=7 indicated the lowest priority. 15Thescramblingcodeselectionfor PRACHtransmissionis evaluateduponOMC provisioned value of ScrambCodeNum parameter. It is also worth to note that message part scrambling code is directly derived from the preamble scrambling code [TS 25.213].UTRAN sets random-access message part structure of radio frame based on provisioned from OMC number of available slot format for random access procedure TotalSlotFormatand direct indication of slot format given bySlotFormat1 SlotFormat2, SlotFormat3, andSlotFormat4parameter value, whichspecifiesthe following items: Channel bit and symbol rate Spreading factor of channelization code Number of bits in the timeslot Number of bits in radio frame Number of user data in the slot #0#1#2#3#4#5#6#7#8#9#10#11#12#13#14 5120 chips radio frame: 10 msradio frame: 10 ms Access slot Random Access Transmission Random Access Transmission Random Access Transmission Random Access Transmission Message partPreamble 10 ms or 20 ms (one or two radio frame) PreamblePreamble 4096 chips Figure 2.1-1 Random Access TransmissionThe UE transmits the preamble in the beginning of time intervals called access slot. Thereare15accessslotsperevery 2 radioframes.Each of themoccupiesatime interval of 5120 chips. Access slots are grouped into 12 sub-channels however consecutive slots belong to the different sub-channel. The classification of access slots into sub-channels is calculated based on broadcasted selection of RACH sub-channels numbersRACHSubChNumand available number 16of subchannels in Access Services Classes identified by parameter AvailableSubchannelNumber [TS 25.214].(Issue: What is assignment algorithm of ASC with RACH subchannel?)An example of relationship between ASC and subchannels is show in the Figure 2.1-2.available preamble signatures(max 16)availablesubchannels(max 12)PRACH partitions(one partition per ASC,max. 8 per PRACH)ASC 0 ASC 1 ASC 2 ASC 0 ASC 1 ASC 2PRACH(max 16 per cell)PRACH 0 PRACH 1RACH(max 16 per cell)RACH 0 RACH 1Preamble scrambling code(max 16 per cell)Preamblescramblingcode 0Preamblescramblingcode 1015011015011ASC 3 ASC 0 ASC 1 ASC 2PRACH 2RACH 2Preamblescramblingcode 209011ASC 0 ASC 1PRACH 3RACH 3Preamblescramblingcode 210 15011Partition not availableon PRACH 2Partition not availableon PRACH 3Coding Coding Coding CodingFigure 2.1-2 Example of RACH/PRACH configuration2.1.1.2 PersistenceUE transmission of random-access information occurs with certain probability characterized by persistence parameter Pi. Each time the UE wants to transmit a transport block to the physical layer it generates a random number between 0 and 1 of the uniform distribution. If this number is lower then Pi value, the UE may start the random-access preamble transmission.The persistence scaling factor provisioned byPersistScalingFactoronly Access Service Class from ASC2 to ASC7.For ASC0 the persistence value P0 has always value of 1 regardless of persistence. The UE has always granted permission to start random-access preamble transmission since this probability is equal to 1.For ASC1 the persistence scaling factor has always value of 1.2.1.1.3 ASC SelectionUE in RRC IDLE ModeAll UEs aremembers of oneout of tenrandomlyallocatedmobilepopulations, defined as Access Classes 0 to 9. The population number is stored in the SIM/USIM. Inaddition, mobilesmaybemembersofoneormoreout of5special categories (Access Classes 11 to 15), also held in the SIM/USIM. These are allocated to specific high priority users as follows. (The enumeration is not meant as a priority sequence):Class 15 - PLMN Staff;Class 14 - Emergency Services;17Class 13 - Public Utilities (e.g. water/gas suppliers);Class 12 - Security Services;Class 11 - For PLMN Use.If theUEis amember of at least oneAccess Class, whichcorresponds tothe permitted classes as signalled over the air interface, and the Access Class is applicable in the serving network, access attempts are allowed. Otherwise access attempts are not allowed.Access Classes are applicable as follows:Classes 0 - 9 - Home and Visited PLMNs;Classes 11 and 15 - Home PLMN only;Classes 12, 13, 14 - Home PLMN and visited PLMNs of home country only.Any number of these classes may be barred at any one time.An additional control bit known as "Access Class 10" is also signalled over the air interface to the UE. This indicates whether or not network access for Emergency Calls is allowed for UEs with access classes 0 to 9 or without an IMSI. For UEs with access classes 11 to 15, Emergency Calls are not allowed if both "Access class 10" and the relevant Access Class (11 to 15) are barred. Otherwise, Emergency Calls are allowed. [TS 22.011, 4.2]. All EmergencyCallsuseASC0, andall ACsbeingintherangefrom0to9are mapped to ASC1. (Parmeter Ac09ToAsc is set to 1). TheAC10toAC15areinturnmapped toASCi, where i=2,,7respectively.Mappingfunctionis specifiedbyfixedassignment ACtoASCbasedonOMC provisionable parameters encoded byAc09ToAsc, Ac10ToAsc, Ac11ToAsc,Ac12ToAsc, Ac13ToAsc, Ac14ToAsc, and Ac15ToAsc tag.Access Classes areonlybeappliedat initial access, i.e. whensendinganRRC CONNECTIONREQUESTmessage. AmappingbetweenAccessClass(AC)and AccessServiceClass(ASC)isindicatedbytheinformationelement "AC-to-ASC mapping" in System Information Block type 5. The correspondence between AC and ASC is indicated as follows.AC 0 - 9 10 11 12 13 14 15ASC 1st IE 2nd IE 3rd IE 4th IE 5th IE 6th IE 7th IEIn the table, "nth IE" designates an ASC number i in the range 0 - 7 to AC.For the randomaccess, the parameters implied bythe respective ASCmust be employed. In case the UE is member of several ACs it should select the ASC for the highest AC number.UE in Connected ModeAt radiobearer setup/reconfigurationeachinvolvedlogical channel isassigneda MACLogical channel Priority(MLP) intherangeform1to8. WhentheMAC sublayer is configured for RACH transmission in the UE, these MLP levels shall be employed for ASC selection on MAC.18The following ASC selection scheme shall be applied, where NumASC is the highest available ASC number and MinMLP the highest logical channel priority assigned to one logical channel: When all Transport Blocks in the TB set have the same MLP, select ASC = min(NumASC, MLP); When Transport Blocks in a Transport Blocks Set have different priority, determine the highest priority level MinMLP and select ASC = min(NumASC, MinMLP).When an RRC CONNECTION REQUEST message is sent RRC determines ASC by means of the access class. [TS 25.321, TS 25. 331](Issue: How does RNC assign MLP?)2.1.1.4 UE MAC Random Access ProcedureThis procedure is executed when the UE MAC entity has some data to transmit. Basically the procedure initiates the random-access preamble transmission based on theresult of Persistenceestimationdescribedabove. Thealgorithmbacksoff for interval of 10ms until preamble transmission is granted again. The successful result of persistence algorithm triggers transmission of preamble.If UEreceives positive AIinAICH, the MAC layer instructs the physical layer to transmit the random-access message part. If UE does not receive any acquisition indicator AI the entire procedure is repeated every 10 ms but no more then a certain maximum number of times indicated by OMC provisionable value of the PreambleRetransMax parameter.If UE receives negative acquisition indicator AI in AICH, the MAC layer procedure is time lagged for sum of 10 ms and some additional number of 10ms-intervals. This additional time interval is randomly selected form the range confined by two OMC provisionable parameters: NB01Min NB01MaxThis sub-routine is repeated no more then number of times given byvalue of PreambleRetransMax parameter.If UEs MAC Layer algorithm cannot initiate the preamble transmission, it reports the failure to the Layer 3 and procedure ends [TS 25.321].2.1.1.5 UE Physical Random Access ProcedureThis procedure allocates and configures parameters related with radio transmission of preamble and message part of random-access information. 19The transmission process begins from selection access slot and signature.TheUEchooses randomlytheULaccess slot amongtheavailable RACHsub-channels and given ASCi, where i=0,,7 based on values encoded into AccessServiceClass parameters. Then the signature selection is carried out based on available signature pool assigned to given ASC and provisioned by OMC configurable parameter values encoded into PreambleSignatures tags. [TS25.214]UE estimates the initial preamble transmission power level assuming identical value of path loss in both UL and DL direction. Preamble transmission initial power setting is explained in Power Control Chapter.IfNode Bdetects and successfully decodes preamble transmission it sends an Acquisition Indicator using AICH.If UE neither receives nor decodes Acquisition Indicator in the following preamble transmissionDLslot onAICH, it repeats preambleretransmissionuptocertain, maximum number of times defined by OMC provisionable parameter PreambleRetransMax. The preamble transition power level is incremented for every next retransmission by ramp step value specified by OMC provisionable parameter PowerRampStep.If UE preamble transmission power exceeds the maximum allowed power by 6 dB the UE exits physical random access procedure [TS 25.214] (see the Uplink Open Power Control Loop section).If no Acquisition Indicator is decoded after maximum number of preamble retransmissions, UE repeats entire procedure no more than Mmax times and then it exits procedure passing a Layer 1 status no ACK on AICH to MAC sub-layer if no acknowledgement is received during that time.If UE decodes negative Acquisition Indicator it exitsphysical randomaccess procedure, passing a Layer 1 status Nack on AICH received to MAC sub layer.If UEdecodes positiveAcquisitionIndicator thenit initiates transmissionof the messagepart. Thetransmissionofrandomaccessmassagestartsafter thedefined number of uplink access slots of the last transmitted preamble. The deferral number of access slots is specified by OMC provisionable parameter AICHTxTiming according to the following rule: If AICHTxTiming = 0 then message transmission starts after 3 access slots, If AICHTxTiming = 1 then message transmission starts after 4 access slots.2.1.2 Related Data base ParametersTag3GPPstandforStandard3GPPparameterandlabel XxstandsforXx implementation specific parameter.20Parameter Name Range Descriptions Controlling CommandPhyChId Value range:0~255; Step: 1 Unique physical channel identifier in the cell. XxADD PRACHASCAccessServiceClass Value range: ASC0, ASC1, ASC2, ASC3, ASC4, ASC5, ASC6, ASC7 ASC identifier 3GPPADD PRACHASCAvailablesignatureStartIndex Value range: 0 ~ 15; Step: 1 Identifies the available signature starting index ofan ASC XxADD PRACHASCAvailablesignatureEndIndex. Value range: 0 ~ 15; Step: 1 Identifies the available signature endingindexof an ASC XxADD PRACHASCScrambCodeNum Value range: 0~15; Step: 1 Preamble scrambling code used by this PRACH preamble part 3GPPADD PRACHBASICPrachSlotFormatNum Value range: 1~4; Step 1 The number of PRACH slot formats available 3GPPADD PRACHSLOTFORMATSlotFormat(i) Value range: 0~3; Step: 1 PRACH timeslot formats available, where i=1,,4 3GPPADD PRACHSLOTFORMATRACHSubChNum Value range: SUBCHANEL0, SUBCHANEL1, SUBCHANEL2, SUBCHANEL3, SUBCHANEL4, SUBCHANEL5, SUBCHANEL6, SUBCHANEL7, SUBCHANEL8, SUBCHANEL9, SUBCHANEL10, SUBCHANEL11. Sequence number of the available sub-channels. The multiple choice is all the 12 sub channels (from sub-channel 0 to 11) 3GPPADD PRACHBASIC21Multiple choiceAvailableSubchannelNumber Value range: 0 ~ 15; Step: 1 The available number of ASC subchannels. XxADD PRACHASCPersistScalingFactor Value range: 0.9 ~ 0.2; Step: 0.1 Factor used to calculate the corresponding dynamic persist value for ASC2-ASC7 XxADD PRACHASCAc09ToAsc Value range: 0 ~ 7; Step: 1 Defines the mapping relation between AC 0~9 and the ASC XxADD PRACHACTOASCMAPAc10ToAsc Value range:0 ~ 7; Step: 1 Defines the mapping relation between AC 10 and the ASC XxADD PRACHACTOASCMAPAc11ToAsc Value range: 0 ~ 7; Step: 1 Defines the mapping relation between AC 11 and the ASC XxADD PRACHACTOASCMAPAc12ToAsc Value range: 0 ~ 7; Step: 1 Defines the mapping relation between AC 12 and the ASC XxADD PRACHACTOASCMAPAc13ToAsc, Value range: 0 ~ 7; Step: 1 Defines the mapping relation between AC 13 and the ASC XxADD PRACHACTOASCMAPAc14ToAsc Value range: 0 ~ 7; Step: 1 Defines the mapping relation between AC 14 and the ASC XxADD PRACHACTOASCMAPAc15ToAsc Value range: 0 ~ 7; Step: 1 Defines the mapping relation between AC 15 and the ASC ADD PRACHACTOASCMAP22 XxPreambleRetransMax Value range: 1 ~ 64; Step: 1 Maximum number of preambles transmitted in a preamble ramping cycle. 3GPPADD PRACHBASICNB01Min Value range: 0 ~ 50; Step: 1 Lower limit of the random back-off delay 3GPPADD RACHNB01Max Value range: 0 ~ 50; Step: 1 Upper limit of the random back-off delay 3GPPADD RACHPreambleSignatures Value range: SIGNATURE0, SIGNATURE1, SIGNATURE2, SIGNATURE3, SIGNATURE4, SIGNATURE5, SIGNATURE6, SIGNATURE7, SIGNATURE8, SIGNATURE9, SIGNATURE10, SIGNATURE11, SIGNATURE12, SIGNATURE13, SIGNATURE14, SIGNATURE15. Multiple choice Sequence number of the available preamble signatures. The multiple choice indicates that all the 16 signatures are available. XxADD PRACHBASICMmax Value range: 1 ~ 32; Step: 1 Maximum number of random access preamble ramping cycles 3GPPADD RACHAICHTxTiming Value range: 0 or 1; The timeslot offset between the access preamble of the PRACH and AICH 3GPPADD AICHPowerOffsetPpm Value range: -5 ~ 10; Unit: dB; Step: 1 Power offset between the preamble and the message part of the PRACHADD PRACHTFC23 3GPPMaxAllowedUlTxPower Value range: -50 ~ 33; Unit: dBm; Step: 1 Maximum allowed power UE transmitted on RACH. 3GPPADD CELLSELRESELGainFactorBetaC Value range: 0~15; Step: 1 UL DPCCH gain set up 3GPPADD PRACHTFCGainFactorBetaD Value range: 0~15; Step: 1 UL DPDCH gain set up 3GPPADD PRACHTFC2.1.3 Key Performance IndicatorsKPI DescriptionsPRACH Message Detection Success RatioPercentageofsuccessfullydetectedPRACHmessagestothetotal number of transmitted PRACH messages by the UE.PRACH Message transmission DelayAverage and 95% percentile of time delay samples measured from the time the first PRACH preamble is sent until the RACH message part is successfully transmitted by the UE (Indicator of delay introduced by the L1 PRACH power ramping procedure).Preamble Detection Success RatioPercentage of the successfully detected PRACH preambles and the total number of transmitted PRACH preambles.RACH Message Tx PowerAverage power level for the RACH messages transmission measured at the output of the UE TX antenna.2.1.4 Optimization Guidelines2.1.4.1 Parameters and RecommendationThe recommendations marked as LAB come form DV&V and performance testing configuration: The recommendations marked as MML come form LMT software release 13.0.0.8.0Parameter Name Recommended ValueSource CommentsPhyChId See planning guideAccessServiceClass ASC0 LabAvailablesignatureStartIndex 0 LabAvailablesignatureEndIndex. 15 Lab24ScrambCodeNum 0 LabTotalSlotFormat NoneSlotFormat1 2 LabRACHSubChNum Subchannel0, Subchannle1, Subchannel2LabAvailableSubchannelNumber 15 LabPersistScalingFactor TBD MML Mandatory only for ASC2-ASC7Ac09ToAsc 1 LabAc10ToAsc 2 LabAc11ToAsc 3 LabAc12ToAsc 4 LabAc13ToAsc,5 LabAc14ToAsc6 LabAc15ToAsc 0 LabPreambleRetransMax 30 LabNB01Min 0 Lab MML recomends 3NB01Max 0 Lab MML recomends 10PreambleSignatures SIGNATURE0, SIGNATURE1, SIGNATURE2, SIGNATURE3, SIGNATURE4, SIGNATURE5, SIGNATURE6, SIGNATURE7MMLMmax 3 LabAICHTxTiming 0 Lab 1 MMLPowerOffsetPpm 4.5 dB Simulation Lab value of 6 dB is excessive.MaxAllowedUlTxPower 24 dBm Lab See planning guideGainFactorBetaC 10 Lab GainFactorBetaD 15 Lab252.1.4.2 Expected KPI ValueTherandomaccessprocedurewasvalidatedintheAHlabtestingfor low 1 DROP LEG Event 1B Event 1A Yes Yes No Change Best Cell Event 1D New Monitored set New SHO params Meas Ctrl msg AS < 3 CAC & OVSF ADD LEG Yes Accept Leg Accept Leg Reject Leg REPLACE LEG Add new cell Delete worse cell AS Update msg AS = AS - 1 AS Update msg AS = AS + 1 AS Update msg AS = AS + 1 AS Update msg Event 1C Figure 4-5. SHO_METHOD2 algorithm processing flow87In addition, cells are also added to the active set on the reception of events 1C or 1D triggered by a monitored cell (not in the active set). In any case, before adding a cell to the active set, radio resources have to be successfully reserved, i.e. radio admission control and OVSF code allocation have to be successful.When the active set is full, the algorithm relies on event 1C to replace an active set cell with a better monitored cell and on event 1D to keep track of the best cell in the active set. When the best cell changes, a newmonitored list is built and a MEASUREMENT CONTROL message sent to the UE to communicate the neighbour list and also update any parameters to the settings of the new best cell.MONITORED LIST DETERMINATIONUSR1 uses the best cell in the active set to control the monitored list. The strategy is as follows: If thereis onlyonecell intheactiveset, useits neighbour list tobuildthe monitored set list. If there is more than one cell in the active set use the neighbour list of the best cell to build the monitored set list. If a 1D event is received, indicating a new best cell, use the neighbour list of the new best cell to build the monitored set list. If the best cell is removed, use the neighbour list of the best cell amongst those left in the active set at that time in order to build the new monitored list.SOFTER HANDOVERThe decision on whether an added radio link should be soft combined with existing radio links at the Node B or whether the new added radio link should be treated as a new SHO leg, is usually left to the Node B. This is achieved by setting the Diversity Control field in the NBAP RL ADDITION REQUEST message to may. Then it is uptotheNodeBtodecidewhether thecurrent radiolinkiscombinedwiththe already existing radio links. However, USR1 allows the modification of this behaviour on a per RNC basis by setting the parameter DivCtrlField differently.DETECTED SET MANAGEMENTThe purpose of Detected Set Management is to utilize the detection capabilities of the UE and provide information for the operator to manually update the neighbour cell list of cells. This can be accomplished by recording the number of times a given cell is detected and the identity of the cells that were in the active set when a given cell is detected.In USR1, reporting of information of the cells in the monitored set can be enabled and disable through the parameterDetectStatSwitchin the ADD CELLINTRAFREQHO command.SIMULTANEOUS AS UPDATE PROCEDURES88The 3GPP standards allowup to 4 active set update procedures to be taken simultaneously. However, USR2 only supports a single ongoing procedure at a time. If measurement reports are received whilst a procedure is ongoing, then those measurement reports are queued and processed afterwards.4.2.2 Related Database ParametersParameter Name Range DescriptionHystfor1A 0 to 7.5 Unit: dB Step: 0.5Hysteresis value for intra-frequency measurement event 1A.TrigTime1A {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000} Unit: msAmount of time to delay the reporting of a 1A event to ensure the criteria are not transient.IntraRelThdFor1A 0 to 14.5 Unit: dB Step: 0.5Relativethresholdforthereporting of event 1A.Hystfor1B 0 to 7.5 Unit: dB Step: 0.5Hysteresis value for intra-frequency measurement event 1B.TrigTime1B {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000} Unit: msAmount of time to delay the reporting of a 1B event to ensure the criteria are not transient.IntraRelThdFor1B 0 to 14.5 Unit: dB Step: 0.5Relativethresholdforthereporting of event 1B.Weight 0 to 1 Step: 0.1Filteringweight tobeusedonthe best cell measurement versus the active set aggregate strength for event 1A/1B.Hystfor1C 0 to 7.5 Unit: dB Step: 0.5Hysteresis value for intra-frequency measurement event 1C.TrigTime1C {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000} Unit: msAmount of time to delay the reporting of a 1C event to ensure the criteria are not transient.Hystfor1D 0 to 7.5 Unit: dB Step: 0.5Hysteresis value for intra-frequency measurement event 1D.TrigTime1D {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000} Unit: msAmount of time to delay the reporting of a 1D event to ensure the criteria are not transient.Hystfor1E 0 to 7.5 Unit: dB Step: 0.5Hysteresis value for intra-frequency measurement event 1E.TrigTime1E {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000}Amount of time to delay the reporting of a 1E event to ensure the criteria are not transient.89 Unit: msIntraAblThdFor1E -24 to 0 Unit: dB Step: 1Absolutethresholdacandidatecell must exceed in order to trigger event 1E.Hystfor1F 0 to 7.5 Unit: dB Step: 0.5Hysteresis value for intra-frequency measurement event 1F.TrigTime1F {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000} Unit: msAmount of time to delay the reporting of a 1F event to ensure the criteria are not transient.IntraAblThdFor1F -24 to 0 Unit: dB Step: 1Absolutethresholdfor acandidate cell to trigger event 1F.DetectStatSwitch {ON, OFF} Monitoringset statistics switch. If enabled, UE measurement reports contain cell status information so as to provide statistic data for network optimisation.DivCtrlField {MAY, MUST,MUST_NOT}Diversitycontrol fieldsent inthe NBAPRLADDITIONREQUEST messageas aNBindicationtodo soft or softer combination.MaxCellInActiveSet 1 to 3 Step: 1Maximumnumber of cells in the active set. This parameter is decided by system specification and so modification is not suggested to ensure correct functioning of the soft handover algorithm.PenaltyTime 1 to 255 Unit: sec Step: 1When a UE is rejected by the admissionandloadcontrol module of a cell, the handover module will resendtherequest toenterintothe cell after the penalty time specified bythisparameter. TheHOmodule continues to try to add the leg for as long as the criteria is met.BEBitRateThd {8, 32, 64, 128, 144, 256, 384} Unit: kbpsThreshold to perform soft handover. If a UE carries best effort traffic at a data rate above this threshold, intra-freqhardhandover is executedon the reception of 1Devents. Note that for CS bearer and CS+PS multirab, soft handover is always used.SHOMethod {SHO_METHOD1, SHO_METHOD2}Soft handover algorithm method selection. There are two soft handover methods in this release: method1isloosemodealgorithm, method 2 is a relative threshold algorithm.Note that all the event 1x parameters are set per cell with the LMT command ADD CELLINTRAFREQHO. However, RNC default values can be set with the command 90SET INTRAFREQHO. This global algorithm parameter configuration is used when cell-specific parameters are not specified.On the other hand, parametersMaxCellInActiveSet,DivCtrlField,PenaltyTime, BEBitRateThdandSHOMethodare set per RNC with the commandSET HOCOMM.HARD-CODED SHO PARAMETERSParameter Name Value DescriptionMaximum AS Size 3 Maximum allowed size of the active set.Triggering Condition 1 Active set It specifies which cells can trigger an event 1B and 1F. It can take on enumerated values: Active set cells, Monitored set cells, Active and Monitored set cells.Triggering Condition 2 Monitored setIt specifies which cells can trigger an event 1A and 1E. It can take on enumerated values: Active set cells, Monitored set cells, Active and Monitored set cells, Detected set cells, detected set and monitored set cells.Replacement_Activation_Threshold3 Minimum size of the active set for event 1C to be triggered.Report_Deactivation_Threshold2 Maximumactive set size for event 1Ato be triggered4.2.3 Most Relevant Key Performance IndicatorsKPI DescriptionSHO RRC Signalling Load(priority=1)Estimation of signalling load (RRCmessages) required to support the soft handover algorithm, and so the processing load associated and backhaul requirements. This is measured in number ofMeasRpt +ASUpdatemessagespercall (and/or sec). Other possibility is to express this in kbps. Simulations have shown the sensitivity of this indicator to sho algorithm implementation.Soft Handover Gain(priority=1)Reduction in UE Transmit Power when a second leg is added to the AS (a cell from a different NB, i.e. selection), compared to that of a single leg.It can be also measured as the reduction of the Eb/No required with several UL/DL SHO legs from the value required with only one leg. This is the Eb/No reduction due to SHO procedureSofter Handover Gain(priority=2)Reduction in UE Transmit Power when a second leg is added to the AS (a cell from the same NB, i.e. combination), compared to that of a single leg.Active Set Size(priority=2) Distribution (historgram) of the number of legs in the active set of a uniformly distributed UE population. High active set sizes may indicate too much overlap between cells and so an increase in neighbour cell interference and a capacity decrease.Softer Handover Factor(priority=2)Percentage of CS/PS calls that are in soft handover, i.e. having one or more additional intra-NodeB radio links91Soft Handover Factor(priority=2)Percentage of CS/PS calls that are in soft handover, i.e. having one or more additional inter-NodeB radio linksSHO Success Rate(priority=1)Ratio of the number of successfull soft handovers over the total number of attempts.Max Power Per Code Hits(priority=2)Percentage of time the Max Power per Code is reached on the downlink, for the duration of the call. Assuming that cell planning and Pwr Ctrl are correct, a high value indicates failure to execute soft-HO on time.Power Imbalance between SHO legs(priority=2)Max difference in EcIo between all cells in the UE active set, for the duration of the call. High imbalance means wrong SHO parameters, since legs with low power compared to the best cell do not contribute to QoS.Power Imbalance between Serving and Neighbour Cells(priority=2)Min difference in EcIo between monitored and serving cells, for the duration of the call. Lowimbalance denotes that the neighbour is a good candidate to be added to the active set.Event1x Reporting Rate(priority=2)Number of measurement reports messages that contain a given intra-frequency SHO event per unit time.Add event response Time(priority=1)Interval elapsed between the time when the UE transmit an add-cell event measurement report and the moment when UE sends the Active Set Update Complete. Note that this time includes the NBAPRadioLinkSetup/AdditionbetweentheRNCandthe Node-B.Delete Event Response Time(priority=2)Interval elapsed between the time when the UEtransmit a delete-cell event measurement report and the moment when UE sends the Active Set Update Complete. Note that this time does not include theNBAPRadioLink Deletion betweenthe RNC and the Node-BDuring the validation of the soft handover algorithmthrough simulations, the following performance metrics were considered. Call quality and outage (average FER over the call duration, per call) RRC signalling load (measurement report and AS update messages) Transmitted power per cell Noise rise per cell Number of active legs per cell Average number of cells and number of Node Bs in the active setThefirst high-level statistics toexaminearethevoicequality(FER) andoutage probability. TypicallytheFERtarget is set at 2%, andtheoutageprobabilityis defined by a FER threshold which was set (arbitrarily for the simulations) at the FER target + 10%, i.e. 2.2%. The meaning of that metric is the percentage of calls that do not meet their QoS criterion. An outage would occur e.g. if the maximum downlink Tx power per code is reached for a long enough period of time. That could happen whentheadditionof abetter cell tothe activeset is delayedduetotheSHO algorithm. This is called call quality outage probability.92The call quality outage probability showed mean values between 1% and 3.3% in the assessment of the original soft handover algorithm in strict mode, which points to a possible problem in the algorithm design. Note that when studying the KPI results, in additiontothemeanvalues, oneshouldalsopayattentiontothedistributionand evolution in time and/or in the cell layout of the metric. Figure 4-6 is an example that highlights situations of unacceptableperformanceof thesoft handover algorithm (even though the mean outage seems low).Figure 4-6. Call quality and outage for original strict mode SHO algorithmAnother key metric for the validation is the RRC signalling load required to support the soft handover algorithm, and so the processing load associated. This includes the number of 1x measurement reports, active set update, active set update complete and measurement control messages. Clearly, the signalling load strongly depends with the UEmobility, cell layout andfadingenvironment, but inthesame situationthis statistic may be a determinant factor to prefer one algorithm to another.Finally, theDLNB transmitpower and UL noise rise characterise the cellload at which the algorithm is being evaluated, but shows little sensitivity to implementation details or parameter settings (at least at low-medium load).4.2.4 Optimisation GuidelinesThesoft handover algorithm(both, SHO_METHOD1andSHO_METHOD2) has beenassessedthroughsimulations, together withtheUSR1OLPCalgorithm. The assessment was carried out in the USS with the purpose of validating the algorithm implementation and its performance with a reasonable set of parameter values. This section presents recommendations based on those simulation results, and the sensitivity analysis carried out, for both soft handover methods supported in USR2.RECOMMENDATIONS FOR SHO_METHOD1Threedifferentscenarioswereconsidered: (i) PED_A at 3km/h,(ii) TU3, and (iii) PED_A at 60 km/h. In all cases, the cell layout consists of 5x5 Node Bs, 3-sector (75 cells), equi-spaced1000mapart, inwrap-aroundmode(noborder effects). The antennapatternhas60beamwidthandamaxgainof 17dB. Theofferedtraffic 93consists of 2,250 voice calls uniformly distributed over the 75 cells. This corresponds to a low-medium cell load (UL Noise rise = 1 dB, DL Tx Pwr = 40%).The choice of radio channel (Pedestrian A vs. TU) has a significant impact on the 1x events parameters, particularly the 1E and 1F thresholds. This is due to the fact that one channel is much more dispersive than the other and the model of the UE pilot measurementsusesonlythestrongestpathtocomputetheEcIo. So, forequal Tx power and pathloss, the EcIo measured at the UE will be smaller for a TU channel compared to a Pedestrian A channel; about 5 dB smaller.Table 4-1 shows the current parameter recommendations for PED_A and TU channel models when using SHO_METHOD1. Although no proper optimisation and sensitivity analysis has been performed on those, they have shown reasonable good performance. Special attention has been paid to the setting of the 1Eand 1F thresholds. In particular, the 1F threshold is set to a lower value (and the hysteresis increased) in the TU environment to account for the lower EcIo measured by the UE. In addition, the 1E threshold, hysteresis and time to trigger are set to the maximum allowed values (0 dB, 7.5 dB and 5 sec) to minimise the probability of event 1E being triggered. Recommended ValueParameter Name PED_A TU3 SourceEvent 1AIntraRelThdFor1A 5 dB SimulationHystfor1A 3 dB SimulationTrigTime1A 640 ms SimulationPeriodMRReportNumfor1A4 SimulationReportIntervalfor1A 2 sec Simulation1A & 1B Weight 0 SimulationEvent 1BIntraRelThdFor1B 5 dB SimulationHystfor1B 3 dB SimulationTrigTime1B 640 ms SimulationEvent 1CHystfor1C 3 dB SimulationTrigTime1C 640 ms SimulationPeriodMRReportNumfor1C4 SimulationReportIntervalfor1C 2 sec SimulationEvent 1DHystfor1D 4 dB SimulationTrigTime1D 640 ms SimulationEvent 1EIntraAblThdFor1E 0 dB SimulationHystfor1E 7.5 dB SimulationTrigTime1E 5000 ms SimulationEvent 1FIntraAblThdFor1F -16 dB -18 dB SimulationHystfor1F 3 dB 4 dB SimulationTrigTime1F 640 ms SimulationDetectStatSwitch OFF EngineeringjudgmentDivCtrlField MAY EngineeringjudgmentPenaltyTime 30 sec MML94BEBitRateThd EngineeringjudgmentSHOMethod SHO_METHOD1Table 4-1. SHO parameter recommendations for SHO_METHOD1The unusual 1E event triggering settings are a consequence of the algorithm implementation details and the changes (CRs) included, specifically due to the use of the 1B and 1F boolean flags. They have been chosen to basically disable event 1E measurement reporting and so make the algorithm work mainly with events 1A, 1B, 1Cand1DasSHO_METHOD2 does.Then,cells are added anddeletedbasedon their relative signal strength and 1E/1F flag is never set. Occasionally, a cell may be dropped by a 1F event when its absolute strength becomes too low before a 1B event is triggered. These settings have been proven in simulations to be a more robust way to run the current soft handover algorithm. SHO settingsParameter Name Config A(1A, 1B, 1C, 1D)Config B(1A, 1B, 1C, 1D, 1E, 1F)IntraAblThdFor1E0 dB -14 dBHystfor1E 7.5 dB 2 dBTrigTime1E 5 sec 640 msTable 4-2. SHO settings to effectively enable/disable event 1EHowever, other settings are also possible. Table 4-2 shows typical settings for normal behaviourinwhich1Eeventisenabled(1A, 1B, 1C, 1D, 1Eand1Fmode). The disadvantage in this case is an increase in the RRC signalling load required, with no gain in terms of radio performance. RECOMMENDATIONS FOR SHO_METHOD2For the evaluation of the SHO_METHOD2 algorithm, two different scenarios have been considered: (i) PED_A at 3 km/h and (ii) PED_A at 10 km/h. The cell layout consistsof5x5NodeBs, 3-sector (75cells), equi-spaced1000mapart, inwrap-aroundmode(noborder effects). Theofferedtrafficis amixof voiceanddata services. The data traffic is best effort performing web browsing sessions with two different RABs, onesymmetrical (64/64kbps) andanother asymmetrical (32/144 kbps), with a BLER target of 10%.The parameter recommendations for SHO_METHOD2 are the same as those shown in Table 4-1, ignoring settings for events 1E and 1F.Table 4-3and Table 4-4show the call quality statistics (measured FER for voice and BLER for data) in uplink and downlink. As it can be seen, the OLPC tends to lead to a lower than requested average FER(0.7%insteadof 1%) andmuchhigher standarddeviation. Thisisaknown behaviour of OLPC (see Power Control section).Voice FER (%)Data BLER (%)95Scenario Traffic mix Mean Std Mean StdPED_A @ 3 km/h Voice only 0.71 0.124 - -PED_A @ 10 km/hVoice + Data (64/64) 0.70 0.180 9.9 0.61PED_A @ 10 km/hVoice + Data (32/144) 0.72 0.239 9.5 6.26Table 4-3. Uplink call quality statistics for SHO_METHOD2Voice FER (%)Data BLER (%)Scenario Traffic mix Mean Std Mean StdPED_A @ 3 km/h Voice only 1.03 0.035 - -PED_A @ 10 km/hVoice + Data (64/64) 1.03 0.035 1.0 0.09PED_A @ 10 km/hVoice + Data (32/144) 1.06 0.066 1.03 0.45Table 4-4. Downlink call quality statistics for SHO_METHOD2Statistics on the RRC signalling load required to support SHO are given in Table 4-5, together with some metrics related to the associated RNC processing load. Finally, the average NodeB transmit power is about 6 W and the uplink noise rise about 1 dB. Typically, only 20% to 30% of the calls have more than one cell in their active set. The full set of simulation results for the validation of the SHO algorithm can be seen in [SEA02-SHO4].Scenario + Traffic mixSignalling Voice only3km/hVoice + 64/6410km/hVoice + 32/14410km/hMeasurement Report 1A 2,162 2,074 1,124Measurement Report 1B 884 1,654 650Measurement Report 1C 385 628 275Measurement Report 1D 867 1,362 599Measurement Report 4,298 5,718 2,648Active Set Update 3,058 4,165 1,971Measurement Control 867 1,362 599Total 11,281 15,140 7,189Avg # MRs per call 1.9 5.1 2.7Avg # AS updates per call1.4 3.7 2.0Avg # Add Leg per call 1.1 2.5 1.5Avg # Drop Leg per call 0.5 2.0 0.9Table 4-5. Signalling and processing load statistics for SHO_METHOD2PERFORMANCE COMPARISON BETWEEN SHO_METHOD1 AND SHO_METHOD2In general, the preferred soft handover algorithm in USR1 is SHO_METHOD2 due to its simplicity,robustness and good performance with lower RRC signalling load. In terms of FER/BLER, outage probability, transmitted power andnoise rise, both 96algorithms deliver similar numbers but there is consistently a slight advantage for the SHO_METHOD2algorithm. Thisisalsotruefortheaveragenumberofcellsand Node Bs in the active set, meaning less modems and less backhaul requirements for the same amount of carried traffic (see [SEA02-SHO3] for more details).However, thereisalargedifferenceintheRRCsignallingloadrequiredbyeach algorithm in terms of measurement reports and active set updates to support the soft handover function. Table 4-6 shows the relative increase or decrease in the total RRC signallingloadcomparedtothatoftheUSSdefaultalgorithm.Itcan beseenthat SHO_METHOD1 is clearly very demanding in signalling load, actually the original SHO algorithm (in load 1.2.0.0.9) was even more demanding. Implementation of the changes does improve things, but the load is still quite higher that that of SHO_METHOD2.SHO_METHOD2 SHO_METHOD1 Original SHOAlgorithmPED_A, 3km/h -11 % 50 % 88 %TU, 3km/h 23 % 41 % 122 %PED_A, 3km/h 4 % 34 % 58 %Table 4-6. Relative RRC signalling load to support SHOFinally, it is recommended from IS-95 experience and earlier simulation results that a value of 0 is used for the Weight factor, so that reporting of relative events 1A and 1B is done with respect to the best cell only, as opposed to some aggregate quantity.SENSITIVITY ANALYSIS OF SHO ALGORITHM (SHO_METHOD2)Further to the previous simulation studies, a sensitivity analysis of the soft handover algorithm was performed, with voice traffic only, in order to investigate the effect of thevariationofanumber ofparametersonthesystemperformance(see[SEA02-SHO9] reports for full details). The emphasis of the analysis was on events 1A and 1B parameters, but also some radio environment factors were varied. Following there is a summary of the findings. Reporting range of event 1A and event 1BVariation of the reporting range of event 1A (R1a) and event 1B (R1b), together with the hysteresis value, effectively changes the size of the handover window, i.e. the difference between the EcIo level at which a cell is added to the active set and that at which a cell is deleted from the active set.For a fixed R1b, the signalling load increases with R1a, both in terms of measurement reports and active set updates. Using R1a=3dBmakes it too difficult foracell tojointheactiveset, whichtranslatesintohigherinter-cell interference and higher number of UEs reaching the maximum power per code in the downlink. On the other hand, R1a=7 dB makes too easy for a cell to join the active set, which means higher signalling load and a larger size of the active set. Therefore R1a=5 dB is a compromise between signalling load, average active set size and radio resource usage.97When R1a is fixed, the average active set size increases with R1b. This is due to thefact that acell canstaylonger intheactive set, evenwhenits EcIois degrading. SoR1b=5dBispreferredover R1b=7dBsinceit leadstolower resource utilisation, although higher RRC signalling. Note that the effect of R1b parameter is compoundedbytheevent 1Cparameter settings, whichmaybe responsibleof deletingcells fromtheactiveset that wouldhavestayedthere otherwise for R1b=7 dB. This is the reason why higher interference level is not shown in the simulations when R1b=7 dB. Time-to-trigger of event 1A and event 1BSimulations from different values of the time-to-trigger parameter for event 1A (T1a) andevent 1B(T1b) intherangefrom0secto1280ms, showedlow sensitivity in the average number of cells and Node Bs in the active set as well as the call quality.Regarding the signalling load, for a given T1b, as T1a increases, the number of MRs triggered by event 1A decreases. Hence, also decreases the number of MRs triggered by other events (1B & 1C) since the average active set size decreases too. For a given T1a, as T1b increases, the number of MRs triggered by event 1B decreases but those triggered by event 1C increases as 1C is triggered before 1B in this situation. Also, since 1C is likely to lead to a swap of cells in the active set, it reduces the number of events 1A too.Results of time-to-trigger values are not conclusive, partly because the KPIs are not appropriate, and partly because it was not foreseen that the settings of event 1C parameters influence the results. Hence a value of 640 ms is initially chosen for both events 1Aand 1B, as a compromise between signalling load and handover speed. CPICH powerThe variation of CPICH power from 1W to 2W, has a clear impact on the network interference level as the minimumdownlink transmit power fromeach cell increases. However, it has no impact on the signalling load or the number of cells andNodeBsintheactiveset. Thisisconsistent withthefact that theSHO algorithm2 does not use absolute events 1E and 1F, but only events based on the relative comparison of EcIo levels. In addition, the voice call quality was identical (meanandstd-devof FER)and meeting the target values. This means that the system was properly dimensioned for 1W CPICH and that no coverage advantage was gained from increasing the CPICH power. Loading (carried traffic)In the simulations, the cell load was increased from 30 to 45 voice calls per cell on averagetoseetheimpacton system performance.Results showed basically no difference in the statistics apart from an increase in the downlink transmit power anduplinknoiserise. Henceitwasconcludethat thesystemcouldhandlethe offered load (note that there is no OVSF code limitation) and that further runs at 60 and 75 voice calls per cell could be of interest.98 Radio channel modelIn addition to the algorithm parameters, the system performance also depends on the characteristics of the radio environment. In the simulations, two different well-known radio models were used, Pedestrian A and Vehicular A. The Pedestrian A channel is not very dispersive. At most two paths contribute significantly to the received signal level and one of them is 10 dB below the other one on average. On the contrary,the Vehicular A model is much more dispersive, with mostly four paths contributing to the signal within 10 dB of each other on average.Results show that the RRC signalling load metrics are not affected by the channel model considered. Thisisclearlyanadvantageof usingsoft handover events based on relative thresholds, which would not be the case with events 1E and 1F. Also, there is an increased downlink transmit power and lower noise rise in the uplinkfor the Vehicular Achannel, as expectedfromthehigher number of multipaths. UE MobilityAs a pilot scenario, a simulation run was carried out increasing the mobility of the UE population to a constant speed of 30 km/h for all mobiles, as opposed to the usual speeddistributionwith16.2km/honaverage, all otherconditionsandparameters being equal. Unsurprisingly, the results showan increase in the measurement reportingrateandactive set update closely related to the speed ratio between both scenarios. Also, the average downlink transmit power increases by nearly 25% while the noise rise is unaffected.4.3 Intra-frequency Hard Handover Although soft/softer handover is the preferred procedure to handle RRC connection mobility in USR2, there are times when only a hard handover can be performed. The hard handover procedure removes all the RL(s) in the active set and establishes new RL(s). An intra-frequency hard handover is only performed when one of the following conditions apply. There is no Iur interface between the source and target RNC. The UE is using a PS RAB at a bit rate above a preset threshold BEBitRateThd.If oneof theconditions describedaboveholds, intra-frequencyhardhandover is performed on the reception of 1D events. Then the handover criteria is controlled by the parameters Hystfor1D and TrigTime1D. Once the hard handover is executed, the monitored set becomes the neighbour list of the new best cell.4.3.1 Optimisation GuidelinesThe parameter BEBitRateThd, gives the operator the possibility to handle best effort serviceswithbit ratesabovecertainthresholdinhardhandover. Thisistoavoid 99employing too many valuable resources (OVSF codes, NodeB power, etc) on radio bearers and coverage areas for which the system has not been designed.0 50 100 150 200 250 300 350 400051015202530354045DL max power per code for Data UE (Voice + Data 64/64)Max Pwr per Code limit (%)#calls64k HHO64k SHOFigure 4-7. Percentage of UEs that reach the max power per code for a service of 64k data, for each simulation run in case of SHO Vs HHOThe question of whether it is more efficient to operate data calls (above certain rate) in hard handover or in soft handover has been initially addressed in [SEA02-SHO3] with a comparison of 64/64 and 32/144 RABs in both soft and hard handover. From the point of view of interference and downlink power consumption, in HHO it is expected higher power tobetransmitted fromonecell, whereas inSHOlower power is expected to be transmitted from more than one cell. This increases the probability of reaching the maximum power per code in the case of HHO as it can be seen in Figure4-7 for the case of a 64/64k data service with and without soft handover. On the other hand, from an OVSF code and backhaul point of view, it is obviously more efficient to operate high data rate services in HHO as less resources are consumed.The balance between hard/soft handover and resource utilisation is closely linked to theguaranteedservicecoveragegivenbytheoperator. Duringcell planning, the network is normally designed to have voice coverage in all the cell area, and also for data services up to a certain rate (usually 64 kbps). Then, for services with a higher rate, coverage can onlybe achieved if soft handover is used, as otherwise the maximum power per code is hit systematically.Then, for even higher rate services, only very limited coverage is possible within the cell, irrespective of whether SHO is enabled or not. A rule of thumb is to set BEBitRateThd to the maximum bit rate with guaranteed cell coverage.1004.4 Inter-frequency Hard Handover 4.4.1 Algorithm OverviewTo allow for multi-carrier deployment, USR2 supports inter-frequency hard handover for both CSand PSdomains. This is necessary to avoid discontinuous carrier coverage during UE movement. This section covers inter-frequency handover due to poor radio link quality but note that the hard handover mechanism is also applied to inter-carrier load balancing (which is covered in another section of this document).Inter-frequency handover is based on a combination of periodic and event-triggered reporting depending on the quality of the used frequency. The UE is commanded to evaluate events 2D and 2F. When the RNC receives a 2D event and the strongest pilot in theactiveset (serving cell)has inter-frequency neighbours, compressed mode is activatedifrequiredandanewMEASUREMENTCONTROLmessageissentto begin periodic measurement reporting of inter-frequency neighbouring cells. Conversely, when the RNC receives a 2F event or the strongest pilot in the active set nolonger hasinter-frequencyneighbours, periodicinter-frequencyreportingends. The flag InterFreqInterRATMeasIndindicates whether the cell has inter-frequency cells, inter-RAT neighbour cells, or both in its idle mode neighbour list (as broadcasted on SIB11). Note that, inter-frequency and inter-RAT compressed mode gap patterns can run simultaneously.Evaluation of2D/2Feventsis made by using either Ec/No or RSCP depending on whether thecell is markedas acentercell or as averge(edge) cell inthe CellProperty attribute. Inter-frequency HHO is permitted from both centre and verge (edge) cells. All that is required is that the serving cell has inter-frequency neighbouring cells defined in the database.The HOSWITCH parameter in the SET CORRMALGOSWITCH command is used to turn on/off this functionality via the INTER_FREQUENCY_HANDOVER_SWITCH flag.4.4.1.1 Inter-frequency Reporting EventsThe events that trigger the reporting of an inter-frequency measurement are described in the following table. Only events 2D and 2F are supported in USR2, in addition to periodic reporting. Note that event 1D is used to detect changes in the strongest active set pilot. This is important for monitoring the strongest pilot neighbour configuration.Event Name Event Description Associated ParametersEvent 2d The estimated quality of the currently used frequency is below a certain thresholdThreshold used frequencyHysteresis valueTime to triggerEvent 2f The estimated quality of the currently used frequency is above a certain thresholdThreshold used frequencyHysteresis valueTime to triggerThecriterionforevents2Dand2Fisdefinedaccordingtoanabsolutethreshold. Measurement reports are generated when the estimated quality of the used frequency is above (or below) a given threshold and the hysteresis and time to trigger conditions 101are fulfilled. The absolute threshold level can be configured in USR2 independently for each traffic type (PS, CS or signalling only), event (2D or 2F) and quantity (RSCP or EcIo) with the parametersInterFreqxThdFor2DyandInterFreqxThdFor2Fy (where x=CS, PS or SIG and y=RSCP or ECIO measurement).The frequencyqualityestimateis defined in 3GPP as an aggregate measure of the quality of all cells in the active set with the following expression.j Best jNij i j j carrier j carrierLogM W M Log W LogM Qj A +

,_

10 ) 1 ( 10 101Where,Qcarrier j is the estimated quality of the active set on frequency j.Mcarrier j is the estimated quality of the active set on frequency j.Mi j is a measurement result of cell i in the active set on frequency j.NA j is the number of cells in the active set on frequency j.MBestj is the measurement result of the best cell in the active set on frequency j.Wj is a parameter sent from UTRAN to UE and used for frequency j.Then, the triggering condition for events 2D and 2F are respectively,2 22 2 2 2 F F carrier D D carrierH Threshold Q and H Threshold Q + Asthemeasurement quantity, bothCPICHEc/NoandCPICHRSCPareusedin USR2 depending on the location of the cell in the network layout. Cells located in the centre ofthecarrierfrequencycoverage use CPICH Ec/No while cells sited in the borderareaofthecarrier coverage use CPICH RSCP as the quality estimate.This behaviour is configured for each cell with the CellPropertyattribute. Consequently, different thresholdsneedtobeset per cell for eachevent typeandmeasurement quantity.The filtering weight Wj defines how much relevance is given to the quality of the best cell with respect to the remaining cells in the active set. This is given in USR2 by the parameter WeightForUsedFreq on a per cell basis.Finally, the hysteresis and time to trigger delay values can be configured per cell in USR2 with the parameters Hystfor2z and TrigTime2z (where z = D or F) respectively.4.4.1.2 Inter-frequency Periodic ReportingOncea 2Deventisreceived by UTRAN in a cell in the boundary to FDD carrier coverage, theUEis configuredtoperformperiodicmonitoringof FDDcells on different frequencies. Theinterval for periodicmeasurementsisconfiguredinthe PeriodReportIntervalattribute. On the reception of a 2F event, periodic inter-frequency reporting is disabled.4.4.1.3 Inter-frequency Hard Handover ProcessingDuring inter-frequency periodic reporting, the RNC receives quality estimates of all (intra-frequency or inter-frequency) cells in the monitored set within the MEASUREMENTREPORTmessage. Then, theRNCestimatesthequalityofthe used frequency with the following equation102, 10 ) 1 ( 10 101H LogM W M Log W LogM Qj Best jNij i j j carrier j carrierj A+ +

,_

Where,Qcarrier j is the estimated quality of the active set on frequency j.Mcarrier j is the estimated quality of the active set on frequency j.Mi j is a measurement result of cell i in the active set on frequency j.NA j is the number of cells in the active set on frequency j.MBestj is the measurement result of the best cell in the active set on frequency j.Wj is a parameter sent from UTRAN to UE and used for frequency j.H is the hysteresis parameter.Then, if the estimated quality of the active set is worse than the reported quality of another carrier andthetimetotrigger conditionis fulfilled, inter-frequencyhard handover is performed. In addition, the quality of the destination cell for the handover has to be above certain CPICH Ec/No and CPICH RSCP minimum thresholds.The expression used to estimate the frequency quality is the same as the one used by the UE for the reporting of events 2D and 2F. However, the equation parameters are different. The hysteresis and time to trigger values for HHO processing are given in USR2bytheparametersHystforHHOandTrigTimeHHO, respectively. Andthe lowest acceptable CPICH RSCP and Ec/No levels of the hard handover destination cell are set in the ADD CELLINTERFREQHO command attributes HHOThdToMacroForRSCP and HHOThdToMacroForEcNo, respectively.Notethat it is onlyduringperiodicreportingthat inter-frequencyhandover may actually occur; reception of events 2D and 2F do not trigger the execution of a hard handover but simply enable and disable compressed mode and periodic reporting.4.4.2 Related Database ParametersNote that inter-frequency handover may need to operate under compress mode, and so relatedparametersneedalsobeset appropriately. Thetablebelowpresentsinter-frequency handover specific parameters. These are set per cell with the ADD CELLINTERFREQHO command.Parameter Name Physical Range DescriptionHystfor2D 0 to 14.5 Unit: dB Step: 0.5Hysteresis value for inter-frequency measurement event 2D.TrigTime2D {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000} Unit: msAmount of time to delay the reporting of a 2Devent toensure the criteria are not transient.InterFreqxThdFor2DEcNo(x=CS, PS, SIG) -24 to 0 Unit: dBAbsolute threshold belowwhich events 2Daretriggered, whenthemeasurement quantity is Ec/No.InterFreqxThdFor2DRSCP(x=CS, PS, SIG) 115 to 25 Unit: dBmAbsolute threshold belowwhich events 2Daretriggered, whenthemeasurement quantity is RSCP.Hystfor2F 0 to 14.5 Unit: dBHysteresis value for inter-frequency measurement event 2F.103 Step: 0.5TrigTime2F {0, 10, 20, 40, 60, 80, 100, 120, 160, 200, 240, 320, 640, 1280, 2560, 5000} Unit: msAmount of time to delay the reporting of a 2Fevent toensure the criteria are not transient.InterFreqxThdFor2FEcNo(x=CS, PS, SIG) -24 to 0 Unit: dBAbsolute threshold the quality of the used frequency must exceed in order to trigger event 2F, when the measurement quantity is Ec/No.InterFreqxThdFor2FRSCP(x=CS, PS, SIG) 115 to 25 Unit: dBmAbsolute threshold the quality of the used frequency must exceed in order to trigger event 2F, when the measurement quantity is RSCP.WeightForUsedFreq 0 to 1 Step: 0.05Filtering weight to be used on the best cell measurement versus the active set aggregate strength for event 2D/2F.HystforHHO 0 to 14.5 Unit: dB Step: 0.5Hysteresis value of the inter-freq hard handover execution. This is a USR2 proprietary parameter.TrigTimeHHO 0 to 64000 Unit: msInter-frequency hard handover trigger delaytime. This is aUSR2proprietary parameter.HHOThdToMacroForRSCP -115 to 25 Unit: dBmThelowest RSCPof theinter-freqhard handover destination cell. This is a USR2 proprietary parameter.HHOThdToMacroForEcNo -24 to 0 Unit: dBThelowest Ec/Nooftheinter-freqhard handover destination cell. This is a USR2 proprietary parameter.PeriodReportInterval {250, 500, 1000, 2000, 4000, 8000, 16000, 20000, 24000, 28000, 32000, 64000} Unit: msInter-frequency measurement reporting period.CellProperty {MACRO_CELL, MICRO_CELL_CARRIER_FREQUENCY_CENTER, MICRO_CELL_CARRIER_FREQUENCY_VERGE, NONLAYERED_CELL_CARRIER_FREQUENCY_CENTER, NONLAYERED_CELL_CARRIER_FREQUENCY_CENTER}Location of the cell in the Network. Cells inthecenterofthecarriercoverageuse CPICH Ec/No as the measurement quantity for inter-frequency reports. Cells in the border area use CPICH RSCP.4.4.3 Most Relevant Key Performance IndicatorsKPI DescriptionInter-Freq HHO RRC Signalling Load(priority=1)Estimation of signalling load (RRCmessages) required to support the inter-Freq hard handover algorithm, and so the processingloadassociatedandbackhaulrequirements. Thisis measured in number of Meas Rpt + Phy Chann Reconfig messages per call (and/or per sec). Other possibility is to express this in kbps.104AMR Quality during Inter-Freq HHO(priority=1)MOS(MeanOpinionScore) duringinter-Freqhardhandover execution for AMR servicesInter-Freq HHO Failure Rate(priority=1)Percentage of attempts failed when the systemis trying to handover the call to another frequencyInter-Freq HHO rate(priority=2)Average number of incoming/outgoing inter-Freq Hard Handovers completed per unit time.Inter-Freq HHO delay(priority=1)Average time required to complete an inter-Freq HHO procedure, from the MR triggered is received until reception of the Phy Chann Reconfig Complete message by the RNCEvent2x Reporting Rate(priority=2)Number of measurement reports messages that contain a given inter-frequency HHO event per unit time.4.4.4 Optimisation GuidelinesThe following values for database parameters are suggested for USR2. Note that these are physical values and that conversion may be required to obtain the RNC database values.Parameter Name Recommended ValueSource CommentsInterFreqxThdFor2DEcNo(x=CS, PS, SIG)-19 dB Simulation Acceptable voice performance up to about -20 dB. See RID-20 reportInterFreqxThdFor2DRSCP(x=CS, PS, SIG)-95 dBm MMLHystfor2D 3 dB MML Common hysteresis valueTrigTime2D 640 ms MMLInterFreqxThdFor2FEcNo(x=CS, PS, SIG)-19 dB Simulation Acceptable voice performance up to about -20 dB. See RID-20 reportInterFreqxThdFor2FRSCP(x=CS, PS, SIG)-90 dBm MMLHystfor2F 3 dB MMLTrigTime2F 640 ms MMLWeightForUsedFreq 0 EngineeringjudgmentHystforHHO 3 dB MMLTrigTimeHHO 640 ms MMLHHOThdToMacroForRSCP-90 dBm SimulationHHOThdToMacroForEcNo -19 dB Simulation Acceptable voice performance up to about -20 dB. See RID-20 reportPeriodReportInterval 500 msec MMLCellProperty - According to cell layout and coverage border areas1054.5 Inter-RAT Hard HandoverThepurposeof theinter-RAThandover procedureisto, under thecontrol of the network, transfer a UE connection from one radio access technology (e.g. UTRAN) to another (e.g. GSM). USR1supports both, handover fromGSMtoUTRANand handover from UTRAN to GSM on CS and PS domains (Cell Change Order), but not simultaneously. This section covers only handover from UTRAN to GSM.4.5.1 Algorithm OverviewIn order to offer worldwide coverage, the handover from UTRAN to GSM is a key feature especially during early deployment stages where islands of UMTS coverage are envisaged. The procedure is initiated fromUTRANwith a RRCmessage HANDOVERFROMUTRANCOMMAND. Then the UE must establish the connection to GSM and release all UMTS radio resources.The handover can be implemented without simultaneous use of two receiver chains at the UE. In this case, the UE can do the measurements by using idle periods in the downlink transmissioncreatedbythe CompressedMode procedure. Compressed Modeisunderthecontrol oftheUTRAN, whichshouldcommunicatetotheUE which frame is slotted (see Section 4.7).Inter-RAThandoverisbasedonperiodicmeasurement reportsandonlyappliesto cells in the UTRAN coverage area, which have GSM cells included in the neighbour list. Initially, theUEiscommandedtoevaluatethequalityoftheusedfrequency through events 2D and 2F, as def