WCDMA Radio Access Network Optimization

Transcription

1 WCDMA Radio Access Network Optimization STUDENT BOOK LZT R1C LZT R1C Ericsson

2 DISCLAIMER This book is a training document and contains simplifications. Therefore, it must not be considered as a specification of the system. The contents of this document are subject to revision without notice due to ongoing progress in methodology, design and manufacturing. Ericsson assumes no legal responsibility for any error or damage resulting from the usage of this document. This document is not intended to replace the technical documentation that was shipped with your system. Always refer to that technical documentation during operation and maintenance. Ericsson 2006 This document was produced by Ericsson. It is used for training purposes only and may not be copied or reproduced in any manner without the express written consent of Ericsson. This Student Book, LZT , R1C supports course number LZU Ericsson 2006 LZT R1C

3 Table of Contents Table of Contents 1 PERFORMANCE MONITORING OF A WCDMA RADIO ACCESS NETWORK...9 INTRODUCTION...13 KEY PERFORMANCE INDICATORS...15 PERFORMANCE MONITORING...17 QUALITY OF SERVICE...18 PERFORMANCE ANALYSIS...20 WCDMA RAN OPTIMIZATION WORKFLOW...21 PREPARATIONS...21 ACCESSIBILITY MODULE...23 RETAINABILITY MODULE...23 INTEGRITY MODULE...23 WCDMA RAN OPTIMIZATION MODULE WORKFLOW...24 PERFORMANCE MEASUREMENTS - STATISTICS...24 PERFORMANCE ANALYSIS...25 RECOMMENDATION & IMPLEMENTATION...27 VERIFICATION OF CHANGES...27 STATISTICAL TEST METHODS DATA COLLECTION...33 DATA COLLECTION...37 BUSY HOUR...37 TYPES OF COUNTERS...39 COUNTER CLASSIFICATION...41 STATISTICS SETUP...42 ACTIVATION...49 STATISTICAL DATA MART SERVICE ACCESSIBILITY...51 ACCESSIBILITY...55 ACCESSIBILITY WORKFLOW...55 LZT R1C Ericsson

4 WORST PERFORMING CELLS...56 UE IN IDLE MODE...58 PLMN SELECTION...59 CELL SELECTION...59 LA AND RA UPDATE...60 PAGING...62 SYSTEM INFORMATION...66 RANDOM ACCESS...68 UL OPEN LOOP POWER CONTROL...70 RRC CONNECTION SETUP...72 EMERGENCY CALLS...73 MODULE MP LOAD...73 ADMISSION CONTROL BLOCK...74 LACK OF TRANSMISSION RESOURCES...90 LOAD SHARING...90 RADIO LINK SETUP...95 NAS PROCEDURES CM SERVICE REJECT RADIO BEARER SETUP UE CELL RESELECTION DURING HANDOVER UE CELL RESELECTION TEMS INVESTIGATION FINDINGS PDP REJECTED PPP LINK CONTROL TERMINATED SERVICE RETAINABILITY RETAINIBILITY RETAINABILITY WORKFLOW WORST CELLS SPEECH VIDEO PACKET SWITCHED DATA DROPPED CALLS Ericsson 2006 LZT R1C

5 Table of Contents UL OUT OF SYNCH CONGESTION WCDMA RAN HANDOVER SOFT/SOFTER HANDOVER HSDPA MOBILITY INTER-FREQUENCY HANDOVER INTER-RAT HANDOVER MISSING NEIGHBOUR RELATIONS OTHER REASONS WNCS (WCDMA NEIGHBOURING CELL SUPPORT) TEMS INVESTIGATION FINDINGS LOSS OF ASU COMPLETE OR MEASUREMENT REPORTS INTER-RNC HANDOVER FAILURE UE RELATED PROBLEM SERVICE INTEGRITY INTEGRITY INTEGRITY WORKFLOW WORST CELLS FORMULAS WCDMA POWER CONTROL CRC CYCLIC-REDUNDANCY CHECK DL INNER LOOP UL INNER LOOP UL OUTER LOOP POWER CONTROL ON HSDPA CHANNELS BLER PARAMETERS PACKET THROUGHPUT HSDPA HW AND SW PREPARATIONS OPTIMIZING THE HSDPA TEMS INVESTIGATION FINDINGS HIGH DL BLER - NO RAB SETUP LZT R1C Ericsson

6 HIGH DL BLER DROPPED CALL UETR AND GPEH UE TRAFFIC RECORDING (UETR) UETR RECORDABLE MESSAGES AND MEASUREMENTS ADD A UETR SUBSCRIPTION PROFILE RETRIVE THE UETR LOGFILES ANALYZE THE UETR LOGFILES GENERAL PERFORMANCE EVENT HANDLING (GPEH) INITIATION OF GPEH GPEH FILES COLLECTION AND STORAGE GPEH FILE STRUCTURE GPEH FILE ANALYSIS USING RED GPEH FILE ANALYSIS USING TEMS ABBREVIATIONS APPENDIX A: CELL PARAMETER AND CONFIGURATIONS APPENDIX B: FORMULAS FOR KEY PERFORMANCE INDICATORS KEY PERFORMANCE INDICATORS ACCESSIBILITY SERVICE SUCCESS SETUP RATE IDLE MODE RANDOM ACCESS ADMISSION CONTROL RETAINABILITY DROPPED CALL RATE MINUTES PER DROP HANDOVER FAILURE RATE INTER-FREQUENCY HANDOVER IRAT HANDOVER CONGESTION OTHER REASONS INTEGRITY Ericsson 2006 LZT R1C

7 Table of Contents BLER THROUGHPUT APPENDIX C: PREDEFINED STATISTICS PROFILES COUNTERS SUMMARY APPENDIX D: TABLE OF FIGURES APPENDIX E: INDEX LZT R1C Ericsson

8 Intentionally Blank Ericsson 2006 LZT R1C

9 1 Performance Monitoring of a WCDMA Radio Access Network 1 Performance Monitoring of a WCDMA Radio Access Network Objectives Upon completion of this chapter the student will be able to: Explain the difference between RAN Tuning and RAN Optimization Describe how to monitor the RAN performance Describe the definition of Network Quality Describe the general optimization process LZT R1C 2006 Ericsson - 9 -

10 Intentionally Blank Ericsson 2006 LZT R1C

11 1 Performance Monitoring of a WCDMA Radio Access Network INTRODUCTION...13 KEY PERFORMANCE INDICATORS...15 PERFORMANCE MONITORING...17 QUALITY OF SERVICE...18 PERFORMANCE ANALYSIS...20 WCDMA RAN OPTIMIZATION WORKFLOW...21 PREPARATIONS...21 ACCESSIBILITY MODULE...23 RETAINABILITY MODULE...23 INTEGRITY MODULE...23 WCDMA RAN OPTIMIZATION MODULE WORKFLOW...24 PERFORMANCE MEASUREMENTS - STATISTICS...24 PERFORMANCE ANALYSIS...25 RECOMMENDATION & IMPLEMENTATION...27 VERIFICATION OF CHANGES...27 STATISTICAL TEST METHODS...28 LZT R1C 2006 Ericsson

12 Intentionally Blank Ericsson 2006 LZT R1C

13 1 Performance Monitoring of a WCDMA Radio Access Network INTRODUCTION This book is aimed for network engineers who need to understand the main issues in optimizing an Ericsson WCDMA radio network. It explains the different steps and tools needed to achieve this from an Ericsson perspective. Common radio related problems are presented and analyzed and the purpose is to create a deeper understanding of radio network optimization, resulting in improvements in radio network performance. RAN tuning is done to provide operators with a detailed understanding of the underlying problems to address, such as network design, UEs and system. It is performed when all necessary nodes in the area are installed and operational and when the network is stable and not yet commercially used. It is also performed when new sites are installed in already commercially launched areas. Figure 1-1 Overview of the Radio Network evolution RAN Optimization is starting when the radio network has been tuned RAN Optimization identifies and solves radio network problems in live networks together with the rising of subscribers in the network. LZT R1C 2006 Ericsson

14 Data from various system sources are analyzed and recommendations are made. Ericsson offers different tools that are used such as performance statistics, User Equipment Traffic Recording (UETR), Cell Traffic Recording (CTR) and General Performance Event Handling (GPEH). Information from drive tests as well as subscriber feedback is also used. Tuning Establish network performance mainly using drive tests: To ensure it is possible to drive in the network without dropping calls To ensure it is possible to set up calls in the coverage area Analyze and describe underlying problems related to: Design UEs Systems Optimization Identify and improve radio network problems using statistics, recordings and events Establish subscriber behavior and perception Ensure that traffic growth can be handled Figure 1-2. The difference between RAN tuning and RAN optimization RAN Tuning is required to ensure good network quality and identifies and solves radio network problems after the network has been installed. RAN tuning is done to provide operators with a detailed understanding of the underlying problems to address, such as network design, UEs and system. It is performed when all necessary nodes in the area are installed and operational and when the network is stable and not yet commercially used. It is also performed when new sites are installed in already commercially launched areas. RAN Optimization can result in changes in the parameter setting for the different functionalities such as idle mode, radio connection supervision, power control, capacity management, handover and channel switching Ericsson 2006 LZT R1C

15 1 Performance Monitoring of a WCDMA Radio Access Network KEY PERFORMANCE INDICATORS To efficiently manage the performance of a cellular network, one must be able to navigate through the data that is collected in the network and determine the areas where improvement is needed. Due to the vast amount of performance statistical data that is collected by the WCDMA network, it can be confusing to correlate all the data for the entire network and build a coherent picture. The solution is to extract and calculate Key Performance Indicators (KPIs), which are directly connected to the quality. Observability covers all functions in UTRAN that serves to monitor and analyze the performance and characteristics of the UTRAN system. This can be done on various levels with different target groups and requirements. The figure below illustrates a model for Observability in UTRAN. Figure 1-3 UTRAN Observability Model The Key Performance Indexes represents the End-user perception of a network on a macro level and are of typical interest for toplevel management as well as others within an operator. These numbers are typically used to benchmark networks against each other and to detect areas of problem. The Performance Indicator level represents information on a system level that does not explicitly qualifies in the macro level end-user perspective model, but can indicate whether the system performs good or bad. Performance Indicators do not necessarily give enough details to allow a full detailed troubleshooting. The data can also be used for planning and dimensioning. This data, typically PM counters and also RES counters, is collected continuously. LZT R1C 2006 Ericsson

16 The Procedure level represents deeper troubleshooting and measure system characteristics measurements. It involves measurement on signaling and procedure/function levels to investigate problems detected on higher levels. The amount of data on this level is enormous and these measurements are generally user-initiated for a specific purpose and area of the network, thereby limiting the scope of the measurements. The typical source for this data is GPEH events and the recording functions UETR and CTR. Examining the KPIs for a network is a primary function of day-today performance management. This will give the operator the information regarding how the network is functioning: Does the network fulfill the performance requirements? Has the performance changed? Improved? Degraded? Where are the problem areas? What types of problems are being experienced? Network performance monitoring is illustrated in Figure 1-4 below. Good? Goal: Perceive the performance at a glance Bad? Information Overflow!!! Solution: Extract and calculate, of all available information, Key Performance Indicators (KPI), which are directly connected to the quality Information about why the network is performing as it is does not need to be provided during this step Figure 1-4 Network performance Monitoring After determining the most pressing issues, the operator can then utilize other statistical and event measurements to isolate issues, troubleshoot the causes, and take the necessary corrective actions. The operator can then use the KPIs to verify that the corrective actions taken resolved the performance issues Ericsson 2006 LZT R1C

17 1 Performance Monitoring of a WCDMA Radio Access Network PERFORMANCE MONITORING The sources for performance monitoring are: Statistical information counters from the network elements Traffic recordings (e.g. UETR, GPEH) Downlink information from single test mobiles (e.g., TEMS Investigation) Downlink information from several special mobiles distributed to selected users Autonomous measurements with special mobile / fixed units (e.g. TEMS Automatic) Customer input (e.g., trouble tickets)since drive testing can be expensive, it isbeneficial to get the information to monitor the radio network performance from the network elements, see Figure 1-5 below. MSC SGSN RNC RNC RNC RBS RBS RBS RBS RBS RBS Network Information UE UE UE Mobile Information Figure 1-5. Measuring Network Quality A great deal of performance management information is available in the Core Network (CN) and the Universal Terrestrial Radio Access Network (UTRAN). Some information, such as idle mode and geographic information, is only directly available from the User Equipment (UE). This information that is not directly available from the network elements can often be estimated by other information that is collected from the network elements. LZT R1C 2006 Ericsson

18 Core Network Other Management Systems Mun OSS-RC Network Management Environment Iu RNC Iur RNC Mur Mut Mub Mun TEMS RBS Iub RANAG Iub RBS RBS Radio Access Network Uu UE UE Uu UE RNC RBS OSS-RC TEMS RANAG User Equipment Radio Network Controller Radio Base Station Operation Support System Radio Core Test Equipment Mobile System Radio Access Network Aggregator QUALITY OF SERVICE Service Accessibility Performance Service Retainability Performance Service Integrity Performance Figure 1-6. WCDMA RAN Architecture Note that the counters are implemented in the network elements (e.g. Radio Network Controller (RNC), Radio Base Station (RBS) and Radio Access Network Aggregator (RANAG), as illustrated in Figure 1-6 above. Hence, statistics are generated by the network elements but stored in a database within OSS. A post-processing tool is needed for analyzing the data and for generating reports. The definition of Quality of Service (QoS) is how the user is satisfied with the overall service. The QoS concept consists of six different requirements (see Figure 1-7): The ability of a service to be obtained within specific tolerances and other given conditions, when requested by the user. E.g. to be able to get in contact with the network. In other words, the operator has to observe the call setup success rate, paging success rate, blocking probability etc. The ability of a service, once obtained, to continue to be provided under given conditions for the requested duration. E.g., the operator has to observe the drop call rate Ericsson 2006 LZT R1C

19 1 Performance Monitoring of a WCDMA Radio Access Network Service Support Performance Service Operability Performance Service Security Performance The degree to which a service is provided without excessive impairments, once obtained. E.g., the operator has to observe the BLER and the throughput. The ability of the operator to provide the service and assists in its utilization. The ability of a service to be successfully and easily operated by a user The protection provided against unauthorized monitoring, fraudulent use, malicious impairment, misuse, human mistake and natural disaster. These six QoS areas are illustrated in Figure 1-7 below. User (subscriber) Quality of service Service Support performance Service Operability performance Service Accessibility performance Service Retainability performance Service Integrity performance Service Security performance Serveability performance Quality of Service Network Performance Provider (operator) Figure 1-7. Network Quality of Service (QoS). By continuously measuring the QoS through monitoring the KPIs, the operator should be able to: Detect problems in the network, and determine if the quality requirements are not fulfilled. LZT R1C 2006 Ericsson

20 Locate problems geographically by isolating which area, cell, or transceiver shows a problem. Detect areas for expansion by monitoring traffic levels and determining where hardware addition is needed. Identify cells that are money makers as a function of traffic carried. This is important in determining the severity of a cell being out of service. PERFORMANCE ANALYSIS Performance Analysis is based on statistics (counters), field DL measurement (TEMS), recordings (e.g., CTR and UETR) and events (GPEH). The measurement results are correlated with information as to how the network is defined (e.g., Configuration Management (CM) data, CM change log) and how the hardware is performing (e.g., Alarm logs). While Performance Monitoring is a function of detecting and localizing performance issues, Performance Analysis is a function of determining the reason(s) for the performance issues and possible solutions. Some of the areas that might need to be addressed are illustrated in Figure 1-8 below: y What creates the problem? How can the problem be solved Problems related to the radio network: Dimensioning, Planning, and Architecture Hardware Problems Uplink (UL) and/or Downlink (DL) Interference Handover (HO)/Inter Radio Access Technology (IRAT) HO Pilot Pollution Idle Mode Parameters Code Allocation Admission Control Connection Handling Power Control Security Other Cell Parameters Figure 1-8 Performance Analyses Ericsson 2006 LZT R1C

21 1 Performance Monitoring of a WCDMA Radio Access Network WCDMA RAN OPTIMIZATION WORKFLOW The main purpose of optimizing a network is to ensure that any service affecting faults related to the traffic load in the network after initial tuning are corrected. Preparations Consistency Check Accessibility module Idle mode P a r a m NAS e t e r s N e i Figure 1-9 Optimization Process Random Access RRC Connection RAB Assignments Retainability module HO Performance Neighbour Integrity module BLER Throughput SF Usage The WCDMA RAN Optimization activity includes the following main tasks shown in Figure 1-9 PREPARATIONS Parameter Settings In order to find this problem and to monitor it is to do a parameter check. There are many problems that can be reduced from start if this is done. (e.g. wrong power settings, wrong handover parameter etc.) Neighbor Relations In order to find this problem and to monitor it is to do a neighbor relations check. There are many problems that can be reduced from start if this is done. If the neighbors are correctly defined, less dropped calls will occur due to missing neighbors or too long neighbor lists. Single defined neighbors will also be identified which reduces the dropped calls. LZT R1C 2006 Ericsson

22 Scrambling codes Statistics In order to find this problem and to monitor it is to do a parameter check. If the scrambling codes are reused to often this can affect the accessibility but also the handover performance due to the UE problem to detect the interfering SC. In order to find the problems in the network, the counters in the NE must be activated, which means that profiles have to be created. More information about this can be found in chapter 2, Data Collection Ericsson 2006 LZT R1C

23 1 Performance Monitoring of a WCDMA Radio Access Network Cell Downtime In order to select the worst performing cells, all cells have to be available for the statistics. If some maintenance has been done on some of the cells, this could have a large impact on the network statistics. These cells should therefore be excluded from the statistics during the maintenance period. pmcelldowntimeman - shows how many seconds during the measurement period cell was manually blocked. During manual downtime cell will not be available for service - pmcelldowntimeauto - shows how many seconds during the measurement period cell was automatically blocked. During downtime cell will not be available for service. Alarms ACCESSIBILITY MODULE RETAINABILITY MODULE INTEGRITY MODULE Before looking for the problem causing sites it is important to fully understand the sites performance in regards of HW faulty. If checking the cells alarms it would give a good indication whether there is a hardware problem at some of the sites. During this module the WCDMA RAN Network accessibility is analyzed. The UE Idle mode behavior as well as the Random Access process is analyzed in order to make the best performance of the network. More information about this module can be found in chapter 3, Service Accessibility During this module the WCDMA RAN Network retainability is analyzed. The UE mobility behavior as well as the handover performance is analyzed in order to make the best performance of the network. More information about this module can be found in chapter 4, Service Retainability During this module the WCDMA RAN Network integrity is analyzed. The BLER is analyzed in order to make the best performance of the network. More information about this module can be found in chapter 3, Service Integrity LZT R1C 2006 Ericsson

24 WCDMA RAN OPTIMIZATION MODULE WORKFLOW Performance Measurements Each module in Figure 1-9 has an own workflow which is shown in the Figure Performance Analysis Figure Module process Recommendation & Implementation Verification of changes Other Modules The process is repeated for each module, where each module represents one area of the service Observability blocks, like accessibility, retainability and integrity (see Figure 1-7. Network Quality of Service (QoS).). PERFORMANCE MEASUREMENTS - STATISTICS Radio network statistics data, i.e. RNC and cell level data should be collected during both busy hours and normal traffic hours. For performance statistics (counters) normally a predefined system profile is up and running in RNC. If this predefined system profile does not cover all counters that are needed for performance monitoring, a user-defined profile should be setup and used during analysis. The following performance areas should be in the performance statistics profile (predefined system profile or/and user-defined profile): RAB Handling, Admission, Admission Monitoring, Cell Availability, Channel Quality, Congestion, Handover, Inter Frequency Handover, IRAT Handover, Processor Supervision, RRC Handling, Iur Channel Handling, Cell update, Connection supervision and Channel Switching Transport network performance statistics (counters) should be collected during the same period that radio network performance statistics is collected. Aal2Ap and VplTp are Managed Objects of interest for transport network that should be monitored Ericsson 2006 LZT R1C

25 1 Performance Monitoring of a WCDMA Radio Access Network The duration of data collection should be for 3-4 days, hours including the busy hours for each day. Data related to the maintenance window s hour should not be used for analysis. OSS- RC PERFORMANCE ANALYSIS Worst cells OSS-RC is needed for creating of new performance statistics or/and UETR/GPEH profiles. The defined profiles will also be activated from OSS. ROP files will be fetched automatically and stored in OSS-RC. Normally the data should be found in the following directors: Performance Statistics.xml files /var/opt/ericsson/nms_umts_pms_seg/segment1/subnetwork Performance Recording.bin files /var/opt/ericsson/nms_umts_red_reg/downloaded For further information on location of the rop files, please see the PM, Subscription Profiles and Performance Monitoring, Function Description - 1/ APR /3) During this performance analysis, KPI from the Performance measurements are evaluated in order to find problem cells or problem geographical areas. The worst cells are divided into several types of worst performing cells and should also be optimized in this specific order. 1. Random access function. The methodology to optimize the random access procedure is very passive due to lack of performance monitoring counter. What can be done is just to adjust the random access parameters and then to observe the variations. Is the number of RRC connection request increased after modifying random access parameters? Is the number of missing RACH message reduced? 2. Accessibility load-sharing (inter-frequency and directed retry to GSM). Is the number of denied admission high in the network? 3. RAB functionality. Identify RAB s that are not performing in line with targets, regarding retainability and integrity. LZT R1C 2006 Ericsson

26 Site configuration Geographic location Drive Tests UETR, GPEH, CTR Review radio parameter settings (points below). Make consistency check of the parameter settings and verify settings against Ericsson default/recommended values. Collect the site and antenna configuration information for every type of these worst cells. Check on map where the worst performing cells are located. Could they be dependent on each other? Normally performance statistics used in the first place to give an overall RNC status and show worst performance cells. During the troubleshooting of call setup problem for worst performing cells, other performance measurements are also needed in order to provide more detailed information to facilitate analysis work. Trouble shooting drive test with TEMS Investigation will be used whenever it is needed to get detailed DL information. Performance Recording applications are used to collect performance events and radio related measurements used for detailed network performance analysis, troubleshooting and network optimization. UETR (User Equipment Traffic Recording) will be used in combination with TEMS Investigation drive test data to provide UL information (excluding reference drive test). UETR performance recording data will be collected after the worst performing cells are identified. If more detailed information is needed, GPEH (General Performance Event Handler) can be used together with the TEMS Visualization. Then multiple calls on the cells guide the optimizer in the right direction in order to implement the changes needed. GPEH is an optional feature and not all operators will have purchased the feature Ericsson 2006 LZT R1C

27 1 Performance Monitoring of a WCDMA Radio Access Network Activate GPEH for more information if needed. GPEH should be used for providing detailed information for worst performing cells. GPEH performance recording data will be collected after the worst performing cells are identified. CTR (Cell Traffic Recording) is a recording of selected performance events, and/or radio related measurements, covering specific cell, usually referred to as the recording area. The main difference between CTR and UETR is that in UETR it is the operator who decides which User Equipments (UEs) to record, while in CTR any UE in a selected area may be recorded. The RNC adds each received measurement and event into the CTR or UETR file (depending on which is activated). The recordings are then accumulated into files for the duration of Report Output Period (ROP), and are stored in the network elements (NEs). The duration of ROP is 15 minutes. RECOMMENDATION & IMPLEMENTATION VERIFICATION OF CHANGES Generally, there will be two types of finding from the data analysis. Either the findings are related to Cell/RBS/RNC parameter settings, or they are related to hardware configuration such as antenna tilt or antenna height etc. A brief report should be produced and presented to the customer, outlining the findings, recommendations and arguments to justify the network changes. The report should provide the customer with necessary input data to be able to understand the nature of the problem, and why the Change Requests (CR) is needed. For every change which is identified as necessary a CR should be raised and submitted to the RND or/and the Operation and Maintenance organization and be agreed upon. Short lead times are expected for implementing short-term changes such as parameters, whilst long-term changes such as hardware configurations may require lead times, which fall outside the time frame of the retainability service. After implementation of changes (parameters, hardware etc) network performance should be monitored in order to verify the impact of changes. Performance statistics data should be collected after change implementation and evaluate the network performance in problem areas and RNC. If for any reason the implemented changes caused any degradation of connection setup in RNC or/and concerned problems areas, the changes should be rolled back and other possible solutions need to be investigated. LZT R1C 2006 Ericsson

28 STATISTICAL TEST METHODS Student s t-test The statistic data should be collected again after both trouble shooting and function. The results should be compared before and after optimization. The paging performance should be checked if it has been improved after previous changes. When performing measurements in a radio network it is important to understand that the system performance can change drastically during a day. When comparing data sets before and after a change it is important to select the measurement occasions so that the different occasions have as equal conditions as possible. There are two commonly used statistical methods when comparing measurements before and after a change in a radio system i.e. adjustment of a parameter or similar. The statistical test methods should give some information on how to judge whether or not a performance improvement has been reached in the system after the change. However these test methods presented below are recommended to use when an improvement after a change in a network is not very obvious statistically due to hourly/daily fluctuation of data. Whenever an improvement is obvious statistically in a network after a change, there is no need to use any test method. Student's t-test, often known simply as the t-test, is one of the most commonly used statistical tests for testing a hypothesis based on a difference between sample means. The t-test determines a probability that two populations are the same with respect to the variable tested. It comes in two versions, the paired t-test and the unpaired t-test. Both versions are used to test the hypothesis that some variable differs between two groups, but the paired test is specifically used when each data point in one group corresponds to a matching data point in the other group. The unpaired t-test is more general. The t-test can be performed knowing just the means, standard deviation, and number of data points Ericsson 2006 LZT R1C

29 1 Performance Monitoring of a WCDMA Radio Access Network Unpaired t-test process The unpaired t-test the most general technique that can be used to test whether a variable differs between two groups, and does not require that the two groups be paired in any way. The samples can also be of different sizes. In simple terms, the t-test compares the actual difference between two means in relation to the variation in the data expressed as the standard deviation of the difference between the means. For the t-test for independent samples, the same number of data points in each group is not needed i.e. the sample taken before may have more data point than the sample taken after. The assumption is that the population follows a normal distribution, or more correct, a t-distribution when the variances are estimated. Below is an example of a network performance improvement activity where a parameter change to reduce dropped call has been verified for the same RNC during different hours before and after parameter change. Hour Drop Before Drop After Table 1- Speech Call Drop for RNC 1. Arrange the data under consideration in two columns as in Table 1. It is assumed that Column Before (column B) contains the sample before and Column After (Column C) contains the sample after a network change. 2. From the Tools option at the top of the Excel screen, select Data analysis to display Analysis options. If Data Analysis is not available, load the Analysis ToolPak from Add-Ins under the tools menu. LZT R1C 2006 Ericsson

30 3. From the drop-down menu select t-test: Two-Sample Assuming Equal Variances 4. Click OK and enter cells B2-B14 for Variable range Select cells C2-C10 for Variable range Set Hypothesized Mean difference = 0 7. Tick the label box 8. Enter a free cell (e.g. E2) for the output range. Choose the top-left cell of the area where the results of the analysis will be displayed. Then click OK and the printout appears as in Table The test will ask what is the probability of obtaining our given results by chance if there is no difference between the means i.e. our Hypothesized Mean Difference is zero or our null-hypothesis zero difference between the samples. Two-Sample Assuming Equal Variances Before After Mean Variance Observations Pooled Variance Hypothesized Mean Difference 0 Df 22 t Stat P(T<=t) one-tail t Critical one-tail P(T<=t) two-tail t Critical two-tail Table 2- Output from unpaired t-test As output from the analysis, the column means are given, the variances of each sample, the number of observations, the hypothesized mean difference, the degree of freedom (df), the calculated t-value (t Stat) and four other entries. The first two of these refer to a one-tailed t-test i.e. if testing only that one particular mean is larger or smaller than the other. The final two entries refer to a two-tailed test, where the direction of the test i.e. is not specified, we do not know if the performance will be better or worse a priori Ericsson 2006 LZT R1C

31 1 Performance Monitoring of a WCDMA Radio Access Network For most purposes, the two-tailed test is used. In each case the probability, P(T<=t) are shown, that the calculated t-value is equal to or less than the tabulated t-value, shown as the t critical. If the P-value associated with the t-test is small i.e. below the risk level of alpha = 0.05, there is evidence to reject the null hypothesis in favor of the alternative. In other words, there is evidence that the means are significantly different than assumed in out null hypothesis. If the P-value associated with the t-test is not small i.e. P(T<=t) > 0.05, there is not enough evidence to reject the null hypothesis, and the conclusion are that there is evidence that the means are not different from the hypothesized value. Thus the reported P(T<=t) two-tail gives the probability of getting the calculated t-value by chance alone. In the example that probability is lower than the risk level of alpha = 0.05, so the sample means are significantly different. It can be stated that the result is 0.19% risk that we reject a null-hypothesis that is true. The conclusion is thus that the drop rate is significant lower afterwards on 5 % risk level. LZT R1C 2006 Ericsson

32 Intentionally Blank Ericsson 2006 LZT R1C

33 2 Data Collection 2 Data Collection Objectives Upon completion of this chapter the student will be able to: Understand what types of counters are available Understand the counter classification Explain how to activate the counters Understand how to calculate busy hour LZT R1C 2006 Ericsson

34 Intentionally Blank Ericsson 2006 LZT R1C

35 2 Data Collection DATA COLLECTION...37 BUSY HOUR...37 TYPES OF COUNTERS...39 COUNTER CLASSIFICATION...41 STATISTICS SETUP...42 ACTIVATION...49 STATISTICAL DATA MART...50 LZT R1C 2006 Ericsson

36 Intentionally Blank Ericsson 2006 LZT R1C

37 2 Data Collection DATA COLLECTION BUSY HOUR Performance Statistics are continuously collected from all Network Elements (NE) and stored persistently in Operation Support System, Radio and Core (OSS-RC). Statistics are mainly used for the detection of problem areas and for monitoring the performance of the network on a daily basis. The complete WCDMA Radio Access Network (RAN) Performance Management (PM) functionality receives support from all WCDMA RAN nodes: Radio Base Station (RBS) Radio Network Controller (RNC) Radio Access Network Aggregator (RANAG RXI) OSS-RC. The traffic nodes provide the performance information through a file interface. This information is collected by OSS-RC. Performance Management Statistical files are stored in OSS-RC for a predefined period of time, where they can be retrieved by interested users. Open interfaces are provided so that report generators and visualizing tools can retrieve the necessary data. The busy hour (BH) can be evaluated per cell for all selected cells. Two alternative approaches can be used for the BH calculation. In both cases, the counters values must be aggregated per cell and per hour (that is for four Recording Output Periods, ROP). BH calculation based on the total number of successful RRC Connection requests BH calculation based on the total payload concerning the traffic carried in both UL and DL on dedicated and common channels, both for PS and CS services. In the first case, the BH evaluation can be based on the pmtotnorrcconnectreqsuccess counter. This counter increases at every successfully established RRC connection. Per cell and within the period under observation, the counter values must be aggregated per hour (normalized to the available ROP periods). LZT R1C 2006 Ericsson

38 The BH must be defined as the hour for which the aggregated value is maximum. In the second case, the BH can be evaluated by considering the total payload considering the traffic carried both in UL and DL on dedicated and common channels (both for PS and CS services). However there are no payload counters specific for HSDPA. The payload traffic counters carried by dedicated and common channels that can be considered for the BH calculation are specified in the table below. Radio Connection type UL Payload counter DL Payload counter Speech pmultrafficvolumecs12 pmdltrafficvolumecs12 PS64/64 pmultrafficvolumeps64 pmdltrafficvolumeps64 PS64/128 pmultrafficvolume Ps128 pmdltrafficvolume Ps128 PS 64/384 pmultrafficvolume Ps384 pmdltrafficvolume Ps384 CS 57.6 (streaming) pmultrafficvolumecs57 pmdltrafficvolumecs57 CS 64 (UDI) pmultrafficvolumecs57 pmdltrafficvolumecs57 Speech/PS 64 multirab pmultrafficvolumecs12ps64 pmdltrafficvolumecs12ps64 PS Common pmultrafficvolumepscommon pmdltrafficvolumepscommon Table 2-1. Counters used for BH calculation Figure 2-2. Example of traffic distributed over 10 days Please note that the BH can occur at different times for different types of services, as shown in the figure above Ericsson 2006 LZT R1C

39 2 Data Collection TYPES OF COUNTERS Peg counters Gauge counters Accumulator counters Scan counters Please note that counter values for all cells might not be available for all of the days and not always for all ROP periods during the day. This could be due to that the RBS can be down, manually or automatically and therefore not available regarding carrying traffic. The names of all the counters created in NEs start with pm, while the names of the OSS-RC calculated statistics counters in start with cm. The following seven types of counters are available in a WCDMA system: A Peg counter is a counter that is increased by one at each occurrence of a specific activity. A Gauge counter is a counter that can be increased or decreased depending on the activity in the system. This can be a ATM Adaptation Layer 2 Access Point Counters, pmexisorigconns, which is the number of existing connections for the AP originating in this node. An Accumulator counter is a counter that is increased by the value of a sample. It indicates the total sum of all sample values taken during a certain time. The name of an accumulator counter begins either with pmsum or pmsumofsamp. A Scan counter is a counter that is increased by one each time the corresponding accumulator counter is increased. It indicates how many samples have been read, and added to the related accumulator counter. A scan counter can therefore be considered a specific kind of peg counter. Due to these types of counters, it is possible to get the average value of all samples by dividing the accumulator counter by the scan counter. The name of a scan counter begins with pmsamples or pmnoofsamp. LZT R1C 2006 Ericsson

40 ATrigAcc counters ATrigAcc counters Probability Density Function counters ATrigAcc counter is a counter that is increased by the value of a sample and the sampling is only done when there is some activity. It indicates the total sum of all sample values taken during a certain time. The sampling is only done if there is some activity ongoing for the measured entity. The name of an TrigAcc counter begins with pmsumact. ATrigScan counter is a counter that is increased by 1 each time the corresponding TrigAcc counter is increased. It indicates how many samples have been read, and added to the related TrigAcc counter. The sampling is only done if there is some activity ongoing for the measured entity. A TrigScan counter can therefore be considered a specific kind of peg counter. Due to these types of counters, it is possible to get the average value of all samples by dividing the TrigAcc counter by the trigscan counter. The name of a TrigScan counter begins with pmsamplesact. A Probability Density Function (PDF) counter is a list of range values. A value is sampled (read) periodically. If the value falls within a certain range, the range counter for that range is increased. All range counter values are collected and stored in a ROP file at the end of each reporting period. For example, if SIR values are split into three ranges: Range1 = [- 11 db -4 db], Range2 = [-4 db +4 db], Range3 = (+4 db +20 db], and a value is read every 3 minutes over a 15 minute period (values = -10, -3, +5, +5, +6), then the three Range Counters are reported as RangeCounter1 = 1, RangeCounter2 = 1, RangeCounter3 = 3 Discrete distributed measurements Figure 2-3. Example of statistics from a PDF counter Ericsson 2006 LZT R1C

41 2 Data Collection Calculated Statistics counters COUNTER CLASSIFICATION Discrete distributed measurements (DDM) are series of values recorded during a reporting period. Each series of values may be of one of the following measurement types: Accumulated over a measurement period and read at the end of each measurement period (a gauge or peg counter) Averaged over the duration of a measurement period Read at a specific time (the measurement time), within the measurement period (at a specific frame) At the end of a series of consecutive measurement periods (the reporting period) all measurement values are collected and stored in a ROP file. For example, if a SIR value is read every 3 minutes over a 15 minute period (values = -10, -3, +5, +5, +6), then 5 DDM measurements are reported as Meas1 = -10, Meas2 = -3, Meas3 = 5, Meas4 = 5, Meas5 = 6. A Calculated Statistics counter is a counter whose value is determined by other counters. The calculation is performed in the OSS-RC Statistics database. The ROP files are opened in order to be transferred into the database and the calculations are made by the database itself during this process. This means that these counters are not available when the Statistics Database is not present. Note: The names of all the counters created in NEs start with pm, while the names of the OSS-RC calculated statistics counters in start with cm. There are two general classifications of the statistic counters. First, they can be grouped depending on where they are generated, that is at which NE or they can be grouped depending on the area of interest that is if they are: Radio Network RNC specific counters Radio Network RBS specific counters Transport Network counters. LZT R1C 2006 Ericsson

42 In the following Figure, the grouping of counters into different NE and different areas of interest is shown. Table 2-4. Grouping the counters based on their NE Origin (SDM = Statistical Data Mart) STATISTICS SETUP Statistics profiles In order to monitor the statistics counter values throughout the time, specific counters have to be active. Only when a counter is active values are generated, collected and can be analyzed. An overview is presented of the counter activation process using the OSS-RC GUI but please note that it is also possible to activate counters through the CORBA interface. For the activation of one or more counters the user has to define a statistics profile. A statistics profile is an entity in the OSS-RC GUI that helps users to manipulate counter administration. The process of creating a new statistics profile is shown in the following figure Ericsson 2006 LZT R1C

43 2 Data Collection Figure 2-5. Statistics profile activation One profile is typically defined in the steps shown corresponding to the figure above: 1. NE type (RNC, RBS or RXI) 2. One or more NE instances It is possible to include one, more or all NE instances into a profile. All the actions performed at the profile will be automatically performed for all the selected NE. Note that if a new NE is setup in the RAN, it will not automatically be included in the existing user-defined profiles. In P4 the user can modify an existing profile and adding NE without suspending the profile (see Modify Active (Admin state) Statistics Subscription Profile in doc USER GUIDE 1/1553-APR /3 Uen B) 3. MO Class (Standard) or MO Instance type (Cell/Cell Relation) LZT R1C 2006 Ericsson

44 The MO Class is normally selected, that is all the existing MO Instances are wanted for a statistics profile. In addition to this it is possible to select only specific cells to be performance monitored. This choice is available only for the RNC for Utran Cell and Utran Relation counters. 4. Cell selection If the MO Instance type is selected for a profile in the previous step, it is possible to select the wanted cells. Only for these cells, the counters (selected in the next step) will be possible to handle through the profile. Note that the MO instance selection is always done on the cell level by the user. The selection of Utran Relations is done automatically based on the cell selection in the following way all the Utran Relations where the selected cells appear as best serving (soft/softer handover) or as source (inter-frequency handover) cells are selected. 5. One or more selected counters (only the counters available to the NE type of the profile) Note that for RNC specific and Transport Network counters it is possible to include and activate more than once the same counter for the same NE for the same MO Instance. This would result in duplicating the data in the statistics ROP files, causing unnecessary increase of their size. It is highly recommended that each counter is activated only once, that is through only one profile. For RBS specific counters this is not valid duplicated subscriptions to already active counters will fail. 6. Scheduling A user-defined statistics profile can be defined as: Continuous the profile state changes only by the user Scheduled the profile starts at a specified point in time and stops after a specified duration Periodical the profile starts at a specified point in time, stops after a specified duration. This is repeated a specified number of times in regular intervals Ericsson 2006 LZT R1C

45 2 Data Collection User-defined and Pre-defined profiles Example: The profile XYZ is an RNC type profile of type Standard (MO Class) for the RNC01 and RNC02 and is including the counters pmcelldowntimeauto and pmcelldowntimeman. It is of type continuous. Once created, the profile may be resumed (state changed to active) or suspended (state changed to suspended). It can also be modified, but only while in state suspended. When a profile is created by a user in OSS-RC it is called userdefined profile. As opposed to user-defined there are pre-defined profiles, which are available immediately after the start-up of new NEs. They do not have to be specially created and they cannot be modified. In the table below, the list and description of pre-defined profiles is given. Network Element Pre-defined Profile Content RNC Primary Counters needed for main Radio Network KPIs RNC Secondary Most important counters for troubleshooting RBS Primary Most important Radio Network counters on the RBS level Table 2-6. Pre-defined profiles In the following table, the main differences between user-defined and pre-defined profiles from the user perspective are shown. Action User-defined Profiles Pre-defined Profiles Create Possible Not Possible Modify Partially * Not Possible Schedule Possible Continuous only Suspend Possible Possible Resume Possible Possible Delete Possible Not Possible** Type MO Instance Possible for RNC for Utran Utran Cell and Utran Relation counters Table 2-7. Main differences between user-defined and pre-defined profiles Not Possible * The operator is allowed to change the attributes of all unlocked user-defined Subscription Profiles with Inactive Admin state and/or change the network element selection for an unlocked, standard user defined standard statistics profile with Active Admin state. LZT R1C 2006 Ericsson

46 ** Pre-defined profiles can still be deleted but only via direct PM IRP operations. Since they cannot be recreated it is strongly recommended to perform the deletion with a great caution and awareness. For more information on what counters that are included in the different predefined profiles, please see Appendix D in this student book. Statistics Scanner Normally, users only need to know about profiles and counters in order to use performance statistics. The statistics profiles are only visible in the OSS-RC GUI. The actual communication between OSS-RC and NEs is performed on another level through statistics scanners. A statistics scanner is a sort of instance of a specific profile at a specific NE. Figure 2-8. Profiles, Scanners and Counters RNC example In the figure above, the concept of profiles, scanners and counters is shown on the example of an RNC node (same applies to RBS and RXI nodes) Ericsson 2006 LZT R1C

47 2 Data Collection One profile (for example the RNC Profile A ) may be mapped to a corresponding scanner ( A ) at several NE instances (RNC1 and RNC2). Another profile (RNC Profile B ) may be mapped to only one NE instance, and so on. Profiles can be active or suspended. When active, all corresponding scanners at selected NEs are also active. When a profile is inactive, all its scanners are also inactive. Normally, the users are handling all the performance statistics administration through profiles. For troubleshooting purposes, or other special cases, it is also possible to resume, suspend and monitor each scanner individually through the OSS-RC GUI and EM. Note that through the EM it is not possible to resume a scanner. Counter limitations There are only two predefined scanners in the RNC. The first, PREDEF.PRIMARY.STATS, contains only the most important RNC radio network counters. These counters are typically used to calculate high-level KPIs. The second, PREDEF.SECONDARY.STATS, contains important counters, typically used for troubleshooting. Both PRIMARY and SECONDARY scanners are initially active on startup of the RNC Which counters that are available in the predefined scanners can be found in the CPI, of Performance Statistics Description 25/1551- AXD /1 Uen H There are limitations on the total amount of counter instances that can be simultaneously active in each NE: RNC 750,000 incrementing counters with R4 HW or later on the O&M board. The RNC can handle 1,700,000 counters in total during a ROP, including counters that have been incremented and zero-value counters. RBS 17,000 counters RXI 65,000 counters Note that these limits apply when up to five scanners are running on the RNC, including the two predefined scanners. With more scanners active, the capacity is lower. LZT R1C 2006 Ericsson

48 Counter Dimensioning For more details on counter limitations please see section 3.4 Counter Limitations in CPI 85/1553-HSD /4 Uen. Rev C. Before activating statistics profiles it is recommended to check if the number of counters would exceed the limits for each NE. It is recommended to, at least initially, do the counter dimension, assuming that all Triggerable counters also are incremented. That means that the dimensioning counter limit, depending on the HW. It is very likely that a quite substantial percentage of the Triggerable counters are not incremented for a specific ROP due to that the triggering conditions for some of the counters are not fulfilled. These non-incremented counters will then be an extra margin. To calculate the Total number of counters and the number of Triggerable counters, a Spreadsheet exists, 5/1553-AXD /1 Uen E. The counter capacities of the RBS and RXI are sufficient for detailed Observability of the nodes. Due to the much higher demand for counters in the RNC, there is a need to carefully optimize the number of active RNC counters. Due to the limitations on the maximum number of simultaneously active counters in one RNC, it may be required to set some rules, depending on the size of the RNC. For small RNC configurations, all defined counters may be simultaneously active everywhere, so the dimensioning is not necessary. For large RNC configurations it is recommended to set the following rules: Keep the primary profile active all the time, thus allowing the radio network KPI performance monitoring on cell and higher levels. Keep the secondary profile active all the time if possible. If not, keep it active all the time when there is no other competing activity. Keep the most important UniSaalTp, Aal2Ap, NniSaalTp, AtmPort, ImaGroup, ImaLink, VclTp, VpcTp and VplTp counters active all the time. This is for the continuous transport network KPI performance monitoring Ericsson 2006 LZT R1C

49 2 Data Collection Define Radio Network troubleshooting clusters, typically about 20 RBSs. Note that when doing a MO instance activation, i.e. selecting a subset of the cells, etc., the maximum limit for each performance monitoring is 72, 000 counter instances. Perform Radio Network troubleshooting on specific clusters, not on the whole RNC. Troubleshoot a function at a time, typically choose between troubleshooting inter-frequency handover, soft/softer handover, inter-rat handover, transport network functions or all other radio network functions. The reason for this is that some functions contribute with a substantial number of counters, so their belonging counters cannot be simultaneously active. Note that some functions counters (handover and all cell based counters) can be activated per cluster and some not (transport network counters). To not create unnecessary large files, use only one measurement (scanner) each for MO class initiated UtranRelation measurements and GsmRelation measurements. If two or more measurements (scanners) are used for MO class initiated UtranRelation measurements, the identity of the UtranRelations are repeated in the file and that will increase the file size considerably. Set the parameter counteralarmthreshold so that a warning alarm is issued when that allowed limit for the Total number of counters is reached. It is by default set to 80%. ACTIVATION Once the wanted profiles and counters are activated, their values are generated and being collected after each reporting period. A reporting period is always set to 15min starting at the 00, 15, 30 or 45 minute in an hour. When all profiles at one NE get suspended, the generation and collection stops for that NE. When a counter is active, a value is generated every Result Output Period (ROP). At the end of each ROP, all the counter values produced during that period are stored in one ROP file at the NE. This file is in XML format and compressed using GZIP. The ROP period is 15 minutes. LZT R1C 2006 Ericsson

50 STATISTICAL DATA MART The statistics ROP files are then collected by the OSS-RC and stored in its file system for a configurable period of time (these values can be changed by modifying OSS-RC parameters. If the Statistical Data Mart (SDM) is present, the data can be stored for up to one year. The Statistics Data Mart is a database available for storing the statistics counters. It provides the ability to store the data for up to one year. All stored data can be accessed through the SQL interface. The SDM offers the ability to aggregate the raw data based on time and object, provides data reliability indicators, and generates the Calculated Statistics counters. The SDM is an optional feature in OSS-RC3 and not standard. The time aggregation is performed for different periods hour, day, peak hours/day and week. The object aggregation is performed only for the Utran Cell counters as they are aggregated on the RNC and then together with other RNC counters up-to System level Ericsson 2006 LZT R1C

51 3 Service Accessibility 3 Service Accessibility Objectives Upon completion of this chapter, the student will be able to: Understand how to analyze and interpret the collected data in order to improve the Call Setup process Analyze RAN performance and propose adjustments related to accessibility LZT R1C 2006 Ericsson

52 Intentionally Blank Ericsson 2006 LZT R1C

53 3 Service Accessibility ACCESSIBILITY...55 ACCESSIBILITY WORKFLOW...55 WORST PERFORMING CELLS...56 UE IN IDLE MODE...58 PLMN SELECTION...59 CELL SELECTION...59 LA AND RA UPDATE...60 PAGING...62 SYSTEM INFORMATION...66 RANDOM ACCESS...68 UL OPEN LOOP POWER CONTROL...70 RRC CONNECTION SETUP...72 EMERGENCY CALLS...73 MODULE MP LOAD...73 ADMISSION CONTROL BLOCK...74 LACK OF TRANSMISSION RESOURCES...90 LOAD SHARING...90 RADIO LINK SETUP...95 NAS PROCEDURES CM SERVICE REJECT RADIO BEARER SETUP UE CELL RESELECTION DURING HANDOVER UE CELL RESELECTION TEMS INVESTIGATION FINDINGS PDP REJECTED PPP LINK CONTROL TERMINATED LZT R1C 2006 Ericsson

54 Intentionally Blank Ericsson 2006 LZT R1C

55 3 Service Accessibility ACCESSIBILITY This is the first module that should be optimized. Accessibility is defined as the ability of a user to obtain requested service from the system. The figure below is showing a mobile originating call setup and all the different actions taken before a call is established. Mobile Originating Call Setup Random Access RRC Connection Setup NAS procedures: Service Request Authentication Security RAB Assignment ACCESSIBILITY WORKFLOW Figure 3-1 A mobile originating call setup and the different action taken Below the Figure 3-2 is showing the Accessibility workflow. At performance monitoring the worst cells regarding accessibility is sorted out. At performance analysis the worst cells are analyzed in the same order as the mobile will originate a call setup. Through the Recommendation and Implementation phase parameters will be looked upon in order to make a change of the networks performance. LZT R1C 2006 Ericsson

56 Through the Verification phase, the collected statistics before anything is implemented is compared to the statistics collected after the implementation is done. This is to ensure that there have been an improvement. Performance Measurements Performance Analysis Idle mode RRC Connection Random Access NAS RAB Assignment pmtotnorrcconnectcssucc pmtotnorrcconnectpssucc pmnorabestablishattempt<rab> pmnorabestablishsuccess<rab> pmnopagediscardcmploadc pmnopagingattemptutranrejected Recommendation & Implementation Squal, Srxlev, qqualmin, qrxlevmin, maxtxpowerul, t3212, t3312, aichpower, poweroffsetp0, preambleretransmax, constantvaluecprach Verification of changes Other Modules Figure 3-2 A The Accessibility workflow WORST PERFORMING CELLS At the end of the workflow, when the verification of the implemented changes is done, then the optimizer should continue to the other modules, in this case the retainability module. The most important is to find the worst cells regarding accessibility. It can be tricky because there are many setup success rates for RRC connection, CS RRC connection, PS RRC connection, CS RAB and PS RAB Ericsson 2006 LZT R1C

57 3 Service Accessibility There are two categories of KPIs: 1 st category KPIs is to identify which cells/rbss having accessibility problems (e.g. RRC connection successful rate and RAB establishment successful rate) 2 nd category KPIs is to imply the reasons of failures (e.g. admission control deny). In order to find areas with high RRC or RAB establishment failures, the 1 st category KPIs should be used to identify the worst performing cells and their surrounding cells. Afterwards, using 2 nd category KPIs estimates the reasons of failures. The issue is which setup success rate(s) should be used for finding worst cells. Therefore, a formula to combine all individual success rates is needed. Then from the result of the formula, worst performing cell can be found by analyzing the setup success rate of a cell with the weight factor (in terms of percentage of RRC attempt, e.g. total number of RRC attempts of that cell / total number of RRC attempts in whole RNC) in a certain time period, for example consequent 7 days. If the optimization strategy is to handle all the worst cells regarding a certain service, then formulas for each service should be used. Accessibility for CS services: pmtotnorrcconnectreqcssuccess pmtotnorabestablishsuccess < RAB > pmtotnorrcconnectreqcs pmmtotnorabestablishattempt < RAB > Where <RAB> = Speech, CS64 or CS57 Accessibility for PS services: pmtotnorrcconnectreqpssuccess pmtotnorabestablishsuccess < RAB > pmtotnorrcconnectreqps pmmtotnorabestablishattempt < RAB > Where <RAB> = PacketStream or PacketInteractive Due to the fact that UE may perform cell re-selection during RRC Connection, it may repeat RRC Connection Request message N300 times which may arrive at different cell, and the fact that WCDMA RAN does not double count the duplicated RRC Connection Request message, there is a chance that access success rate for some cells may show larger than 100% success rate. LZT R1C 2006 Ericsson

58 UE IN IDLE MODE The access success rate of better than 100% happens when the attempt registered at different cell than where the success registered. The end result is slightly larger success rate for the cell that completes the access and a slightly less success rate for the cell that starts the access. The Idle mode tasks may be divided in five different processes: PLMN selection and reselection Cell selection and reselection Location area (LA) and routing area (RA) registration Paging procedure Reading system information Most of the faults in a network appear after the cell has selected the PLMN and made a cell selection. However sometimes problems can occur that are related to the UE idle mode behavior. Figure 3-3 illustrates the relationship between PLMN selection, cell selection and reselection and LA and RA registration. Automatic/Manual mode selection Indication to user PLMN Selection PLMN selected PLMNs available Cell Selection/Reselection LR Response Registration area changes Location registration Figure 3-3 The relationship between some of the idle mode tasks Ericsson 2006 LZT R1C

59 3 Service Accessibility PLMN SELECTION CELL SELECTION PLMN selection is the first step in the registration process that allows a UE to carry out or receive services from an operator. The UE normally operates on its home PLMN. However, a Visited PLMN (VPLMN) may be selected if the UE loses coverage. A UE successfully registers on a PLMN if it finds a suitable cell to camp on within the selected PLMN. The UE will then obtain a location or routing registration acknowledgement in the area of the cell on which it is camped. The UE displays to the user that this PLMN is registered. When a UE does not find a suitable cell in the selected PLMN, it tries to camp on any other acceptable cell within an allowed PLMN. When there is a suitable cell available normal services can be obtained in the cell. If there is an acceptable cell available only emergency calls are available. One of the requirements for a suitable cell is to fulfill cell selection criteria. The UE bases its evaluation on two quantities: Squal and Srxlev. The cell selection criteria are fulfilled when: Squal = Qqualmeas- qqualmin > 0 Srxlev = Qrxlevmeas qrxlevmin Pcompensation > 0 Where Pcompensation = max(maxtxpowerul P;0) qqualmin is sent in the broadcast information (SIB 3 for serving cell and SIB 11 for adjacent cells) and indicates the minimum required quality value. The UE measures the received quality, Qqualmeas ; on the CPICH (CPICH Ec/No) and calculates Squal. This is only done for WCDMA cells. qrxlevmin is also sent in the system information (SIB 3 for serving cell and in SIB 11 for adjacent cells) and indicates the minimum required signal strength. The UE measures the received signal Code Power (CPICH RSCP) and obtains Srxlev LZT R1C 2006 Ericsson

60 maxtxpowerul is the maximum transmission power during random access on the RACH and that value is sent in the system information (SIB 3). P is the UE maximum output power according to its class. Quantities measured and parameters used are shown in Figure 3-4. Qqualmeas Qrxlevmeas CPICH P-CCPCH qqualmin qrxlevmin maxpowerul LA AND RA UPDATE Figure 3-4 Determination of Cell Selection Criteria The UE shall measure the CPICH Ec/No and the CPICH RSCP of the serving cell and evaluate the cell selection criterion, S, at least every DRX cycle. The UE shall filter the Ec/No and RSCP measurements of the serving cell using at least two measurements. If both criteria are fulfilled and other requirements for a suitable cell are fulfilled the UE will camp on the cell. The UE will enter the state camped normally where it performs intra-, inter- and intersystem radio measurements to evaluate if a neighbouring cell is better than the serving one. Location and routing areas are used by the CN for mobility functionality. A paging message for a CS call to a certain UE is broadcasted to all cells belonging to the LA in which the UE is registered. Accordingly, a paging message for a PS connection is broadcasted to all cells in the RA in which the UE is registered Ericsson 2006 LZT R1C

61 3 Service Accessibility The CN has to keep track of the location of the UE. To make this possible the UE registers to the CN at certain instances. Specifically when moving from one LA to another, the UE performs an LA and/or RA Update (LAU/RAU). If the LAs/RAs are small, there will be more LAUs/RAUs in the system. On the other hand, if the LAs/RAs are large the number of paging messages will increase. There are three types of LA and RA registration updates: 1. International Mobile Subscriber Identity (IMSI) attach or detach 2. Normal LA and RA updating 3. Periodic LA and RA updating Periodic registration (LA and RA updating) is used to locate the UE to avoid unnecessary paging attempts for a UE that has lost coverage and is not able to inform the CN that it is inactive. A timer t3212 controls the periodic LA update procedure and gives the time interval between two consecutive periodic location area updates. The timer is sent in the system information. When the UE is in connected mode and t3212 expires no periodic update is performed. When the UE enters Idle mode again a LA update is performed, see Figure 3-5 UE in idle mode UE moves to connected mode UE moves to idle mode t3212 t3212 LA Update LA Update LA Update Figure 3-5 Periodic Registration A timer, called t3312, which gives the time interval between two consecutive periodic routing updates, controls the periodic RA update. The value of the timer is sent by the CN to the UE in the IMSI attach or in the routing area update message accept (this is not a radio parameter). LZT R1C 2006 Ericsson

62 The intensity of RRC connection establishments is considerably higher for RBSs placed at the LA/RA border compared to RBSs placed inside the LA/RA. A border RBS can therefore handle less traffic than an RBS placed inside the LA, due to the increased signalling load. Therefore, it is recommended that he LA/RA borders should be placed in areas with low traffic. A high number of border RBSs will increase the signalling load in the RNC for the same number of subscribers. If the LAs/RAs are small, the number of border RBSs will be large. Therefore, the LAs/RAs must not be too small. Different PLMNs and thus different Location/Routing Area Identification (LAI/RAI) should be used for the GSM and WCDMA networks. If the same LAI/RAI is used for the GSM and WCDMA networks, the consequence is heavy paging load in the WCDMA network arising from the GSM subscribers. PAGING Paging is initiated upon request from the CN or triggered in UTRAN. It is used to notify the UE of different events. In WCDMA RAN P4 these are: UE terminating service request for PS or CS services (CN initiated). CN initiated paging is applicable to UEs in idle mode. UTRAN initiated broadcast to inform UEs when System Information is modified. UTRAN initiated paging is used whenever System Information (e.g. information about cell selection/ reselection, addition/replacement of neighbors, handover etc.) has been updated. The paging message has the following characteristics: Type of paging message: Paging Type 1 or Paging Type 2 UE identity used in the message (IMSI, TMSI, P-TMSI) The physical radio channels and type of resource required The area in which the page will be broadcasted (LA or globally) The paging record varies in length depending on whether it includes the UE identity in terms of IMSI, TMSI, or P-TMSI. A PCH frame can carry one Paging Type 1 message of 10 ms and may contain between 3-5 paging records, depending on whether the paging uses IMSI or TMSI/P-TMSI Ericsson 2006 LZT R1C

63 3 Service Accessibility When the UE mode is Cell_FACH or Cell_DCH common or dedicated physical channels are already in use and the paging message Paging Type 2 will be used. For paging, the capacities of the FACH and the RACH are assumed to be enough, but there is a risk of congestion in the PCH due to heavy paging load. Therefore, the probability of congestion in the PCH must be calculated in order to dimension the LA/RA. If the operator wants to check the paging success rate, this should be done on MSC level. Notice that even if a UE does not response to a paging in a certain Location Area, a second paging might be sent throughout the whole MSC area (depending on configuration) and UE can be finally reached. For this reason the most reliable indicator for paging is the one obtained at MSC level. Successful First and Repeated Page attempts of total number of first attempts, Paging success rate in a MSC NPAG1RESUCC NPAG1GLTOT + NPAG2RESUCC NPAG1LOTOT Paging start in the core network but the paging flow in the RAN network is only considered. Total number of pages discarded due to central MP load control for a RNC pmnopagediscardcmploadc Pages request rejection for a cell pmnopagingattemptutranrejected Paging intensity per cell in a RNC (if RNC, LA and RA consist of exact same cells): pmcninitpagingtoidleuela + pmcninitpagingtoidleuera + pmcninitpagingtoidleue measurement period total number of cells in that RNC LZT R1C 2006 Ericsson

64 In the Figure 3-6 the dashed arrows and boxes considers the packet switched paging. For all counter flow, the following are applied: RBS counters: <Counter Name> (Green color) RNC Counters: <Counter Name> (Blue color) MSC Counters: <COUNTER NAME> (Orange color, capital letters) Exceptions, Failures: Successful Outcomes: Counter Scope: (Scope) <Counter Name> Ericsson 2006 LZT R1C

65 3 Service Accessibility RNC received Paging message from the CN Connected Check UE status (RNC) pmcnopagingattemptcninitdcch + RNC Sends to the UE Paging Type 2 Message Yes Idle MP Overload? (RNC) pmcnopagdiscardcmploadc + No Paging is not sent Paging Area is a defined LA? Yes No Yes Paging Area is a defined RA? (RNC) pmcninitpagingtoidlela + (RA) pmcninitpagingtoidleuera + No (RNC) pminitpagingtoidleue + Yes Paging que full? (Cell) pmcninitpagingattemptutranrejected + No Paging is not Sent Paging is Sent Figure 3-6 The Paging counter flowchart LZT R1C 2006 Ericsson

66 SYSTEM INFORMATION The System Information Block (SIB) messages are sent on BCCH logical channel, which can be mapped to the BCH for UEs in idle mode, Cell_PCH and URA_PCH or the FACH transport channel for UEs in Cell_FACH. The system information explains for the UE how to behave in the cell and it carries for example information that the UE needs for cell reselection. The system information elements are broadcasted in System Information Blocks. A SIB groups together system information elements of the same nature, for example cell selection and reselection parameters. The SIBs are sent in System Information messages. Different system information blocks may have different characteristics for instance regarding their repetition rate and the requirements on UEs to re-read the SIBs. The SIBs are organized as a tree. A Master Information Block (MIB) gives references to a number of SIBs in a cell, including scheduling information for those SIBs. In addition to scheduling information of other SIBs, the MIB contains only information of supported PLMN types (which can be GSM and/or ANSI 41) and PLMN identity information. The MIB is transmitted according to standardized scheduling parameters, so a UE is always able to find the MIB on the BCCH. The MIB carries information of when the UE can expect to find the different SIBs. To inform the UE if a change in System information has occurred, the MIB also delivers a value tag for each SIB. This is to prevent unnecessary decoding of same information. The tag is used by the UE to detect a change in SIB. If the tag is changed, UE needs to reread the information. If no change in the value tag, the SIB is discarded or not read. To inform UEs in idle mode, Cell_PCH and URA_PCH of a change in the system information, paging in used. In this case, a Paging type 1 message is sent to deliver the IE BCCH modification info to notify the new value tag for the MIB. WCDMA RAN can also inform of the change in the system information with a System Information Change Indication message on the FACH transport channel Ericsson 2006 LZT R1C

67 3 Service Accessibility Contents The table below contains a description of the information that is carried by the MIB and the SIBs. MIB PLMN Identity X LA and RA updating X Cell Selection and Reselection Parameters X X Power Control on Common Channel X Paging Parameters X Measurement Management X X Cell and common channel configuration X Timers and counters in Idle mode X SIB 1 SIB 3 SIB 5 SIB 7 SIB 11 When a suitable cell is found, the UE camps on it in a state defined as camped normally. In this state, the UE monitors paging and system information, performs radio measurements, and evaluates cell reselection criteria. If the UE finds a better cell, the cell reselection process selects that cell. The change of cell may imply a change of the Radio Access Technology (RAT). SIB 12 LZT R1C 2006 Ericsson

68 RANDOM ACCESS Random Access is the same for every kind of service: CS, PS, Registrations, Signaling, SMS, etc. The UE is in idle state when it is sending the RRC Connection Request message. The RNC has correctly received the request over the Random Access Channel (RACH). However if the RNC does not receive the RRC Connection Request message the UE returns in Idle state. NAttempts =0 NAttempts =+1 NAttemptsi > N300 (=5)? No Yes Random Access Failure UE sends preambles sequences No response is sent and/or received by UE over AICH Negative AICH is sent (Cell) pmnegativemessages + Positive AICH is sent (Cell) pmpositivemessages + (Cell) pmfaultytransportblocks + UE does not receive positive AICH UE receives positive AICH UE sends message RRC Connection Request RNC does not receive the message RNC receives the message (Cell) pmtotnorrcconnectreq + (Cell) pmtotnorrcconnectreqcs + (Cell) pmnorecrandomaccsuccess + (Cell) pmtransportblocks + Figure 3-7 The Random Access counter flowchart Ericsson 2006 LZT R1C

69 3 Service Accessibility There is no statistic counter to directly present that random access procedure failure behaviour. However, the preamble or AICH counters can be analyzed in order to determine the probability of occurring random access procedure failure problem. If maximum allowed attempts (N300=5) has been reached the cause of failure is that the RBS has blocked the access (negative AICH) or preambles sent by the UE are not received or ignored (no AICH is sent) or UE does not receive the AICH positive for any reason. During the RACH procedure, the UE is allowed to make a cell reselection, so it is possible that a few attempts have to be repeated because the cell changed. In case of cell reselection or when the response from the RNC is delayed more than T300 (=1 sec) more than one RRC Connection Request could be sent to the RNC. Only the first attempt is counted by pmtotnorrcconnectreq and pmtotnorrcconnectreqcs counters. In case trouble-shooting drive test is done, from TEMS, the symptoms of this problem are: 1. UE repeatedly prepares RRC connection request messages in L3. 2. UE camps onto a cell and does not change cells. 3. However, the UE does not receive RRC connection setup or RRC connection reject message. Please note that under random access problem, the UE TX power does not reach to the maximum allowed UE TX power. This should be compared when the UE does ramp up the UE TX power to its maximum allowed TX power. The reason for this can be an UL/DL unbalance or swapped feeders. The possible reasons why UL/DL is in imbalance are too large CPICH power setting, imbalance in UL/DL feeder loss, high UL RSSI noise rise and cell down. The primarycpichpower could be set too large or the UL RSSI is too high. It is also important to verify if there is any mistake in the antenna system configuration and feeder attenuation settings in the system. If the preamble and RACH message part are wrongly recognized or lost, it could also be that the AICH power is not large enough. The solution is to check if the aichpower is set as default. If needed, increase aichpower. LZT R1C 2006 Ericsson

70 UL OPEN LOOP POWER CONTROL Power Control is essential for the smooth operation of a WCDMA system, because all users share the same radio frequency band using different codes. There are three types of power control in WCDMA as illustrated in Figure 3-8. BLER:Block Error Rate SIR: Signal to Interference Ratio TPC: Transmit Power Control Uplink SIR target Uplink outer loop Downlink outer loop BLER-Measured Inner loop SIR-Target modified Downlink TPC Uplink TPC Downlink SIR target Open loop Starting power BLER-Measured Uplink SIR-Target SIR-Target modified Uplink SIR error RNC Figure 3-8 WCDMA Power Control Open Loop Power Control is performed in the uplink and downlink to calculate a minimum starting power for setting up a connection. In doing so the interference and power required is minimized. The suitable settings should fulfill below criteria: poweroffsetp0 x preambleretransmax + constantvaluecprach >= predefined preamble threshold, and n x poweroffsetp0 + poweroffsetppm >= 0, where n can be in 0 to preambleretransmax range Number/percentage of false detections, which is the case that preamble is detected but there is no enough energy in message part, due to noise on the random access channel for a carrier (it could be due to loss of AICH, wrong recognition of preamble or loss of RACH message part after the UE sends message out): pmnopreamblefalsedetection or pmnopreamblefalsedetection 100% pmpositivemessages Ericsson 2006 LZT R1C

71 3 Service Accessibility Signal-to-interference ratio of all access attempts above the preamble threshold (except false detection) on RACH for a carrier: pmreceivedpreamblesir and Number of samples of pmreceivedpreamblesir The solution to the problems is to check if the parameters are set properly. If needed, increase constantvaluecprach or/and poweroffsetppm LZT R1C 2006 Ericsson

72 RRC CONNECTION SETUP The RNC has received RRC Connection Request message from the UE and the UE has successfully establish a RRC connection. The RNC receives both the Radio Link Restore Indication from the RBS and the RRC Connection Setup Complete from the UE. RNC receives the message RRC Connection Request Context allocation failure UE context allocation (Cell) pmnoofredirectedemergencycalls + (Cell) pmnorejrrcconnmmploadc + (Cell) pmnoreqdeniedadm + Load Sharing Redirection of Emergency Call Access not allowed Access not allowed Load Sharing RRC Redirection OK Emergency Call No Processor Load control (MP) OK Admission Control OK Multifrequency Load Sharing No Channel code allocation (Cell) pmnodlchcodeallocattemptsf128 + Code not available (Cell) pmnodlchcodeallocfailuresf128+ (Cell) pmnofailedafteradm + (UL BBP) pmsetupfailuresf64 + (DL BBP) pmsetupfailuresf128 + RAX or TXB Congestion OK Radio Link Setup (UL BBP) pmsetupattemptssf64 + (DL BBP) pmsetupattemptssf128 + (Cell) pmtotnoutranrejrrcconnreq+ RNC sends the message RRC Connection Reject AAL2 Failure AAL2 Setup OK RNC sends the message RRC Connection Setup Figure 3-9 A mobile originating call setup and the different action taken Ericsson 2006 LZT R1C

73 3 Service Accessibility EMERGENCY CALLS MODULE MP LOAD The UE always initiates the establishment of an RRC connection by sending the RRC Connection Request message with an establishment code (Emergency call, Registration, Originating Call, IRAT Cell Reselection...). When the redirect of emergency calls to GSM feature is turned on, the request to establish an RRC connection shall be rejected for all UEs indicating 'Emergency call'. The following RNC counters, counts the number of successful emergency positioning attempts. pmpositioningreqsuccesagps 100% pmpositioningreqattesagps In P5 Emergency calls can be served and positioned in UMTS if the operator has confidence in AGPS in UMTS otherwise the call is handed over to GSM When the feature is 'on' and in operation the following parameter settings are needed in order for the call to have the possibility to be served in UMTS and positioned by UMTS: eccnsbhorequestignore = TRUE, eclocationattemptumts = Yes For UMTS cells where the operator is confident AGPS is performing well enough to meet the positioning requirements of emergency calls set the agpsenable= True. Congestion control and admission control will not block emergency calls. RRC connection rejection rate due to module MP load control for a cell could be found in the following formula: pmnorejrrcconnmploadc pmtotnorrcconnectreq - pmnoloadsharingrrcconn 100% Note that RRC connection rejection due to module MP load control happens before inter-frequency load sharing. One reason for MP load can be too many periodic registrations LZT R1C 2006 Ericsson

74 ADMISSION CONTROL BLOCK Admission control is together with Congestion control part of the WCDMA Capacity Management. The setting of parameters associated with Admission control can have a serious effect on Network Capacity and revenue generated. Admission control blocks new incoming calls as well as handover attempts when the load in the system is high. By doing that, the call dropping probability is reduced. Admission control is used in both the uplink and downlink. The admission decision is based on air interface load, by using measurements of uplink interference, downlink output power as well as the actual number of users. The admission functionality is also capable of including priority, for instance emergency calls, in the admission decision. In the illustration in Figure 3-10 the last UE is blocked because the cell load has reached the defined admission limit. Admission limit Cell Load RBS Figure 3-10 WCDMA Capacity Management (Admission Control) Admission Control blocks due to improper admission threshold settings. There are nine admission policies to control the blocking. They are UL ASE, DL ASE, DL TX cell power, spreading factor usage, code usage, Hw usage, amount of HS users, congestion and number of users in compressed mode. Understanding of which cause(s) to trigger blocking is necessary to solve the problem Ericsson 2006 LZT R1C

75 3 Service Accessibility RESOURCE REQUEST NO, then accept Is admission control blocked by congestion control? NO YES, then block Check if the requested + est # compressed mode RL > CompModeAdm Check if the requested HW + estimated HW > ulhwadm, dlhwadm YES, then block NO NO YES, then block Check if the requested + estimated code usage > DlCodeAdm Check if the requested + estimated # HS users > hsdpausersadm YES, then block NO NO YES, then block Check if the requested DL SF + estimated Dl SF > SfXAdm, NO Sf = 8 sf =16 sf = 32 NO Check if the requested DL pwr + estimated pwr > pwradm YES, then YES, then block Check if the requested ASE dl + estimated ASE dl > AseDlAdm NO Check if the requested ASE Ul + estimated ASE Ul > AseUlAdm YES, then block Figure 3-11 The Admission control flow When new resources are needed for a radio connection, (a new radio link is set up or an existing radio link is modified), the Admission Control function receives a request for admission. The request specifies the estimated amount of dedicated monitored resources that the radio connection needs. This estimation is compared to the available resources and the configured limits for admission set by the operator, and a response is sent out to grant or deny the new radio link access to a cell. To decide on the requests, the Admission Control function requires information about the load on the dedicated monitored resources and the amount of resources needed by the requester. LZT R1C 2006 Ericsson

76 Admission Control has different policies regarding the maximum level of the dedicated monitored resources it rejects or admits radio links. Admission Control is responsible for dividing the available resources among the non-guaranteed service class connections, and for differentiating access to resources between guaranteed and nonguaranteed service class connections, as well as reserving part of the dedicated monitored resources for hand over of connections. Counter pmnoreqdeniedadm pmnofailedafteradm Description Number of RAB establishment and RRC requests denied due to AC, both drifting and non-drifting UEs. This counter is increased when admission is denied for radio resources. Number of RRC establishment requests and RAB establishment requests failed after being admitted, both drifting and nondrifting UEs. This counter is increased after the admission is accepted for radio resources issue, but when it is denied due to a shortage of transport network resources/channel elements The counter pmnoreqdeniedadm shows the number of RRC establishment requests and RAB establishment requests denied for a cell. Please note that this counter is stepped up for RRC establishment, RAB establishment or channel up-switching if admission control triggers the blocking in a cell. The solution to the admission control blocking problem is to check if the admission thresholds (i.e. ulhwadm, hsdpausersadm maximumtransmissionpower, aseuladmoffset, bemarginasedl, bemarginaseul, bemargindlcode, compmodeadm, dlcodeadm) match to the original planned capacity. If the thresholds do not match to the original planned capacity, the admission thresholds have to be corrected. Otherwise, re-do the radio network dimensioning to increase the system capacity or activate the inter-frequency load sharing to increase the trucking efficiency Ericsson 2006 LZT R1C

77 3 Service Accessibility Congestion control blocks Congestion control is used to resolve overload in both the uplink and the downlink. As shown in the figure below, congestion due to radio overload in uplink is detected when the uplink Received Total Wideband Power (RWTP) exceeds a certain configurable threshold for a longer time than the hysteresis time. The threshold for detection of uplink congestion is determined by ifcong + ifoffset and the hysteresis time is determined by ifhyst. Congestion Control considers uplink congestion to be resolved when the uplink RTWP for a particular cell is below ifcong for a longer time than the hysteresis time (or until the next periodic event-based measurement report for uplink RTWP arrives indicating that the resource level is below the threshold). Figure 3-12 Detection of Uplink Cell Congestion Due to Uplink Received Total Wideband Power The current default setting is defined so that guaranteed-hs users are never released (releaseasedlghs=0). The reason for this strategy is that one HS contributes marginally to the downlink cell congestion because there is only one A-DCH channel per HSDPA user in downlink. Acting on the non-guaranteed and guaranteed service class is, under normal circumstances, sufficient to resolve the congestion in the cell. The admission control also controls the blocks due to congestion. Therefore is it important to look at the congestion counters. Number of times congestion control is triggered due to high DL power for a cell: pmsumoftimesmeasoldl Number of times congestion control is triggered due to high UL interference for a cell: pmsumoftimesmeasolul LZT R1C 2006 Ericsson

78 pmnooftermhscong & pmnoofiurtermhscong - RNC counters monitoring no. of HSDPA users released due to congestion The total amount of time (sec) was congested in DL during a reporting period for a cell: pmtotaltimedlcellcong The total amount of time (sec) was congested in UL during a reporting period for a cell:pmtotaltimeulcellcong Samples of the UL RSSI for a cell-carrier could be found in the counter pmaveragerssi. By using these samples the formulas for getting the average DL and UL. Average DL TX power for a cell-carrier: 102 pmtransmittedcarrierpower i = i = 0 i pmtransmittedcarrierpower Average UL RSSI for a cell-carrier: 62 i = 0 [ pmaveragerssi ( 0.5 i 110.5) ] 62 i = 0 pmaveragerssi i i i For averaging RSSI and carrier power, these values must be checked close to the maximum allowed values. If the average values are close to these thresholds, it implies the chance of having congestion/admission block is high. In fact, it will be more interesting to look at max RSSI and carrier power sampled values. Still as RL setup is taking very short time to establish, it will be very hard to say how those max values are related to RL failures. In TEMS Investigation, this can be found by verifying that the UE send RRC Connection Request, UTRAN send RRC Connection Reject with cause = congestion. i Ericsson 2006 LZT R1C

79 3 Service Accessibility Figure 3-13 TEMS Investigation with high UTRA Carrier RSSI The UL RSSI can be high due to the following: non-traffic interference High TX power from a UE that are connected to a far cell. This can happen due to missing neighbors. RBS HW The RBS Hardware Monitor provides Admission Control with the estimation of the hardware usage in a local cell group, separately for the uplink and the downlink The relation among the RBS hardware admission policy parameters, the downlink resource usage in the relevant local cell group and the admission request parameters are almost the same as the uplink resource check as shown below. LZT R1C 2006 Ericsson

80 Figure 3-14 The Uplink RBS HW Admission Policy It is worth noting that the soft congestion mechanism on the downlink hardware resource will consider the connections in the related cells on cell group level as possible targets. For example, if an admission request is blocked on downlink hardware, one connection in the cells connected to the same hardware group is possibly targeted with a down-switch (in case there is a valid candidate). If there are a lot of admission blocks due to RBS HW the solution to this is either a parameter change or adding new hardware with the license keys that are retrieved by contacting Ericsson product management. The total amount of RBS hardware that can be used might be limited by the following capacity keys: WCDMA RBS key for Capacity UL CXC /4002 WCDMA RBS key for Capacity DL CXC /4003 The keys set a limit on the available amount of Channel Elements that may be utilized simultaneously in the RBS, separately for uplink and downlink. Three parameters, ulhwadm, dlhwadm, bemarginulhw and bemargindlhw, are related to the RBS HW resource control Ericsson 2006 LZT R1C

81 3 Service Accessibility HS Users The HS-DSCH is a shared transport channel. If a very large amount of users simultaneously are assigned to this channel the throughput per user can become very low. If that is the case, no user might experience a sufficient end-to-end quality. Therefore, it can be beneficial to the operator to be able to limit the number of users that can be allocated to the HS-DSCH in a cell. Admission Control blocks new radio link admission requests which involve the allocation to HS-PDSCH/HS-SCCH when the number of users assigned to the HS-DSCH in the cell exceeds hsdpausersadm. If UL 384 is active, an HSDPA RAB establishment is attempted first on the 384/HS RAB. If for some reason (admission, failed path loss check) the packet call cannot be setup on the 384/HS RAB, an attempt is made on the 64/HS RAB provided that the hsdpausersadm value is not exceeded. Note that the HSDPA admission policy is only applied to requests for new HSDPA connections, which follow the Serving HS-DSCH Cell Selection during RAB Establishment. Therefore, requests related to mobility of existing HSDPA connections, which follow the Serving HS-DSCH Cell Change, are never blocked by the HSDPA admission policy. DL TX Power Three parameters, pwradm, bemargindlpwr and pwradmoffset, are related to downlink transmitted carrier power and are used by Admission Control to decide which admission requests to admit or reject. The operator can limit the total maximum power utilized by R99 connections that is allowed to be transmitted by an RBS in a cell by setting maximumtransmissionpower. The remaining power can then be used for transmission of HS-PDSCH/HS-SCCH channels to HSDPA users This parameter is used when setting up or reconfiguring a cell; when maximumtransmissionpower is higher than the maximum downlink power capability reported by the RBS maxdlpowercapability, the latter is automatically taken as limit of the total maximum power allowed in the cell. This mechanism simplifies setup and reconfiguration of cells and enables the UTRAN to handle changes in RBS maximum downlink power capability in a transparent fashion. LZT R1C 2006 Ericsson

82 By changing the pwradm setting, the portion of downlink power reserved for HSDPA connections can be increased or decreased. The default settings balance a mix of R99 and available power for HSDPA, providing a minimum of 25% power to HSDPA, except for those cases when R99 takes part of that power due to mobility and power variations of users in the cell. For a cell with predominantly R99 traffic, it is possible to increase the power admission threshold in order to maximize capacity. An option is to make use of the complete capability before the congestion resolve mechanism is activated, which is possible thanks to the fast congestion control mechanism in the RBS. This is achieved by setting pwradm + pwradmoffset + pwroffset equal to 99% (so that congestion resolve actions can still be triggered). The pwradm can be set to 84% maintaining pwradmoffset at 10% and pwroffset at 5%. In order to make sure that no negative impact is produced by such a change, dropped calls and soft handover failures should be carefully monitored. Figure 3-15 The Downlink Transmitted Carrier Power Admission Policy When admission requests are blocked by Admission Control, the soft congestion mechanism is activated. This mechanism consists of down-switching an existing non-guaranteed service class connection to a lower bit rate in downlink, after blocking a (nonguaranteed <any>) admission request of a lower rate or a (guaranteed <any>) request. Soft congestion mechanism allows the control of the accessibility for guaranteed service class connections in the system, and the control of the sharing of the available resources among non-guaranteed service class connections in the system Ericsson 2006 LZT R1C

83 3 Service Accessibility The default admission threshold for guaranteed service class connections (pwradm) has been set to limit the risk of running into too frequent downlink cell congestion situations under the conditions mentioned. Depending on mobility and service mix situation in the cell (and the specific behavior of the UEs), the admission limit can be increased or decreased. Note that, when changing, it might be required to reconsider the settings for the hand over margin (pwradmoffset), the margin for non-guaranteed service class connections (bemarginpwradm) and the cell congestion detection margin (pwroffset). The default hand over margin for the downlink transmitted carrier power resource (pwradmoffset) has been set to have a trade off between the smallest possible reservation for hand over connections and the reasonable blocking for hand over connections. In case of a higher percentage of connections in hand over in a cell and a high experienced blocking of those connections (i.e. resulting in connections being dropped), this margin should be increased. The margin for non-guaranteed service class connections in a cell bemargindlpwr has to be tuned according to the required reservation of downlink air-interface resources for guaranteed service class connections in a cell. Note that the setting will influence the intensity of the soft congestion actions on nonguaranteed service class connections in the cell. Samples of the DL TX power for a cell-carrier could be found in the counter pmtransmittedcarrierpower. This counter is an RBS PDF counter, this includes the power used for HSDPA as well. If checking the nonhs users transmitted carrier power the counter pmtransmittedcarrierpowernonhs should be used. How many down-switches due to best effort clean up, which is triggered by DL TX power and code usage admission policies can be found in the counter pmnoofswdownngadm. LZT R1C 2006 Ericsson

84 ASE block The ASE of a single radio link depends on the radio connection type and is expressed in terms of the equivalent number of speech radio bearers that generate the same amount of air-interface load. Using this definition, a radio link that has, for example, an ASE of three in downlink is expected to generate as much interference in downlink as three speech radio bearers in the cell. The default setting for the admission policy for the Air Interface Speech Equivalents (ASE) in uplink aseuladm is based on the characteristic dimensioning of the system not to be loaded more than 60% of its pole capacity. In the downlink, the downlink transmitted carrier power is the main dedicated monitored resource used to control the air interface load. asedladm is a complement to the load control when the cell can support so many users that it is close to the pole capacity, which can cause instability. Therefore, if the downlink transmitted carrier power is the limiting resource, asedladm can be set very high, so it does not interfere with the control strategy used for the downlink transmitted carrier power. In uplink, besides uplink Congestion Control, ASE is the only resource that is controlled to allow admission and modifications. Therefore, the parameters that regulate the uplink ASE admission policy need to be set in order to minimize the risk of going into uplink overload. Figure 3-16 The Uplink ASE Admission Policy Ericsson 2006 LZT R1C

85 3 Service Accessibility For downlink, there is a similar pattern to uplink between the parameters and the ASE monitor policy. Counter pmsumofsampaseul pmsumofsampasedl pmnoofsampaseul pmnoofsampasedl Description Total ASE UL, that is sum of all sample values recorded Total ASE DL, that is sum of all sample values recorded Number of samples of ASE UL increased at every occasion when the corresponding Sum counter is increased, sampled every 30 seconds Number of samples of ASE DL increased at every occasion when the corresponding Sum counter is increased, sampled every 30s The formulas for checking the average usage of ASE in the downlink and uplink for a cell can be found below. Average UL ASE for a cell: Average DL ASE for a cell: pmsumofsampaseul pmnoofsampaseul pmsumofsampasedl pmnoofsampasedl Spreading Factor usage policy Admission Control controls the spreading factor usage in the downlink at cell level and the number of radio links in compressed mode. Admission Control blocks non-guaranteed service class radio links depending on the spreading factor usage monitored by the Histogram Monitor. LZT R1C 2006 Ericsson

86 Figure 3-17 The Spreading Factor Admission Policy for Non-guaranteed Service Class Radio Links Note that (guaranteed, <any>) access requests are not influenced by the admission policy, but their contribution to the resource utilization is considered in the monitor. Admission Control blocks (guaranteed, <any>) admission requests demanding spreading factor 16 in downlink (streaming PS16/128 radio connection type) when the usage of this spreading factor exceeds sf16gadm. By limiting the amount of streaming PS16/128 users that can share the system resources with other guaranteed service class radio connection types, it is possible to differentiate accessibility of system resources between high (streaming PS16/128) and low consuming radio links within the guaranteed service class. Admission Control blocks (guaranteed-hs, <any>) admission requests demanding spreading factor 4 in uplink (PS384/HS radio connection type) when the usage of this spreading factor exceeds sf4admul. In cells where the optional PS384/HS radio connection type is activated, sf4admul can be reduced if the uplink is experienced as problematic, for example due to high RTWP or transport network problems. To prevent unavailability of the transport resources for guaranteed service class connections, the spreading factor usage policy could be defined by setting sf8adm, sf16adm, and sf32adm in a certain way. Note that this could increase the blocking in the radio network, while blocking on the transport network resources is reduced (although that is the reason for blocking) Ericsson 2006 LZT R1C

87 3 Service Accessibility Downlink code allocation policy The 384/HS RAB is enabled by setting the parameters allow384hsrab to TRUE and sf4admul to a value higher than zero. In cells without any R99 load, field tests have shown that up to four simultaneous UL 384 connections with high activity can be handled without generating excessive interference. In reality, assuming that the probability of having as many UL 384 connections with the highest activity at the same time is very low, sf4admul can be set to a value up to 4, taking into consideration that: As no UL channel switching is implemented in P4, allowing many 384/HS users in a cell implies a high channel element consumption, which reduces the amount of hardware resources that could be allocated to other services. sf4admul should be low in cells where there are no separate AAL2 path resources configured for HSDPA traffic in order to save transport network resources for non- HSDPA traffic. Uplink interference should be constantly monitored as increased activity in the uplink can create system instability and dropped calls. Note that the aseuladm default value needs to be increased so that four UL 384 users can be accommodated. To reserve codes for users in hand over, there is code blocking for non-hand over requests, while requests for hand over are not blocked by the downlink channelization code admission policy. It should be noted that hand over requests can fail on the allocation of the downlink code and this is detected when allocating the downlink code. The default admission limit dlcodeadm is set to 80% (reserving 20% of the code tree for new handover legs). This setting is intended for HSDPA enabled cells and is equivalent to a dlcodeadm of 75% when HSDPA is not enabled in the cell. In a network with a high degree of R99 packet users or cells with both HSDPA and R99 traffic, this value needs to be increased even further in order to avoid unnecessary code blocking. Setting dlcodeadm to 85% and bemargindlcode to 5% will maximize the code tree usage and still allow a margin for new soft handover legs. LZT R1C 2006 Ericsson

88 The operator can configure the number of HS-PDSCH codes (SF=16) that should be allocated for a HSDPA capable cell by setting numhspdschcodes. The maximum number of HS-PDSCH codes is five. Note that the number of HS-SCCH codes (SF=128) is fixed to one, since code multiplexing is not supported, that is never more than one user is transmitting per subframe. The operator has the possibility to configure and change the number of HS-PDSCH codes allocated in a cell for HSDPA by tuning numhspdschcodes. The default value (5) aims at maximizing the peak rate of users using the HSDPA feature. When reducing the number of HS-PDSCH codes numhspdschcodes, the codes that are to be released are transparently de-allocated, without affecting ongoing traffic. Conversely, in case of an increase, the cell will temporarily be disabled due to its implicit lock/unlock, leading to the release of all the ongoing traffic in the cell. Figure 3-18 The Downlink Channelization Code Admission Policy Non-guaranteed, non-handover admission requests are blocked when the resource usage exceeds dlcodeadm - bemargindlcode. These service classes can be Packet Switched data and multirab speech service Guaranteed, non-handover and guaranteed-hs, non-handover admission requests are blocked when the resource usage exceeds dlcodeadm. These service classes can be Circuit Switched data, HSDPA as well as the packet switched streaming service Ericsson 2006 LZT R1C

89 3 Service Accessibility The counter shows the number of RRC connection requests and RAB establishment denied by admission control due to lack of power, code utilization limit, ASE limit and compressed mode limit. pmnoreqdeniedadm The blocking probability can be used together with Erlang metric to measure the cell capacity for a given service. Since a cell serves a mixed traffic, this measure must be used with respect to the amount of traffic measured for other services. When a request is blocked on the downlink channelization code admission policy, the soft congestion mechanism is triggered. Code allocation failure for SFn, where n is the spreading factor for a cell could be found in the following formula (as an example the SF128 was used): pmnodlchcodeallocfailuresf128 pmnodlchcodeallocattemptsf % The solution to this problem is to add more carriers or sectorization to reduce the code usage of the cell Compressed mode The setting for the compressed mode admission policy, compmodeadm, restricts the number of users in compressed mode. If the presence of compressed mode connections using SF/2 compressed mode technique is high and the quality of the common channels in a cell is degrading, it can be desirable to restrict the number of radio links that are allowed in compressed mode in the cell How many users are in compressed mode? Well the average number of user in compressed mode for a cell: pmsumcompmode pmsampescompmode LZT R1C 2006 Ericsson

90 LACK OF TRANSMISSION RESOURCES LOAD SHARING In P4, transmission resource is not checked in admission control. Therefore, there is probability of having blocking due to lack transmission resources. The number of setup failures on the downlink baseband pool due to TXB congestion for a RBS, pmsetupfailuressf4, pmsetupfailuressf8, pmsetupfailuressf16, pmsetupfailuressf32, pmsetupfailuressf64, pmsetupfailuressf128, pmsetupfailuressf256 Normally, in mobile network, the bottleneck for accessibility should not be on transmission part, i.e. 100% AAL2 establishment success rate. However, in WCDMA, requested bandwidth for high data rate services becomes high and as a result, some cells can perform badly. AAL2 establishment failure can be observed by: Non-zero radio link setup failure rate in RRC establishment with no admission control blocking, no code allocation failure, no HW failure High number of interactive RAB failure (= low interactive RAB establishment successful rate) but not much admission control blocking. Suggestions to the transmission problems are to add additional E1 (The temporary solution is to set sf8adm = zero so as to reduce the critical in E1 bandwidth usage) and if necessary, further study on GPEH s admission control internal event to obtain the exact reason why admission control blocks the setup Load sharing (see Figure 3-19) enhances the performance of a Radio Access Network by pooling together resources from different parts of the entire network. Currently, two load-sharing features are available in the WCDMA RAN: Inter-Frequency Load Sharing Directed Retry to GSM The Inter-Frequency Load Sharing is activated in an RNC by setting the parameter loadsharingrrcenabled to TRUE. Loadsharing neighbors must be defined before any load-sharing action can take place Ericsson 2006 LZT R1C

91 3 Service Accessibility Directed Retry to GSM is activated in an RNC by setting the flag loadsharingdirretryenabled to TRUE. Inter-Frequency Load Sharing diverts incoming traffic from a more loaded cell in one WCDMA carrier to a less loaded one in another WCDMA carrier. Directed Retry to GSM is a one-way diversion from WCDMA to GSM. Both features are implemented entirely in the RNC. Figure 3-19 Load sharing Idle state cell-reselection can also balance cell load to some extent. The 3GPP standard specifies two alternatives for selecting the best cell for a UE in the idle state: the measured quality (E c /N 0 ) or the measured signal strength (RSCP) of the CPICH. In Ericsson systems, E c /N 0 is used. This indirectly takes into account the cell load. The load of a WCDMA cell depends on many factors, such as downlink power, uplink interference, code utilization, etc. For loadsharing purpose, only the downlink transmitted carrier power is considered since that is most often the limiting factor on the capacity of a cell. To better reflect the available resource in a cell, cell load is measured as the ratio between the downlink transmitted carrier power and the admission limit, as given by the cell parameter pwradm. For HSDPA cells, only the non-hsdpa part is counted, i.e., the cell load for load-sharing purpose does not include the power used for HS-PDSCH and HS-SCCH. The downlink transmitted carrier power for the non-hsdpa part is measured by the RBS and periodically reported to the RNC. LZT R1C 2006 Ericsson

92 In order to perform the necessary evaluation for making a load sharing decision, a cell has to be aware of the load of all of its loadsharing neighbors. Inter-Frequency Load Sharing is performed during the RRC connection establishment procedure and Directed Retry to GSM during the RAB establishment procedure. With Inter-Frequency Load Sharing, the cell load is measured directly in terms of the actual downlink power. A UE will be guided to the most suitable cell during the RRC connection establishment. The load sharing can be monitored by the counters: pmnoofreturningrrcconn, pmnoloadsharingrrcconn Load Sharing RNC sends RRC Connection Reject message including the Redirection Info IE that tells the mobile to try to access the network via the specified frequency (Cell) pmnoloadsharingrrcconn + (Cell) pmtotnoutranrejrrcconnreq + The UE reselects a cell in the specified frequency and tries to access the network The UE succeeds to setup RRC conn. in the new freq? No Does the UE return back to the original frequency? No RRC Conn. Setup Failure. UE goes back to idle state Yes Yes (Cell) pmtotnorrcconnectreqsuccess + (Cell) pmtotnorrcconnectreqcssuc + (Cell) pmnoofreturningrrcconn + Random Access Load Sharing is not allowed in this 2nd access attempt Figure 3-20 The load sharing counter flow Ericsson 2006 LZT R1C

93 3 Service Accessibility Ratio between RRC connection returning and redirection due to load sharing for a cell: pmnoofreturningrrcconn pmnoloadsharing RrcConn RRC Connection Redirection In order to reduce RRC Connection direction problems is to do a parameter check. There are many problems that can be reduced from start if this is done. If there is a too large difference of the pilot power setting between two carriers, it will cause a higher redirection rate. The parameter primarycpichpower should be checked between the carriers. Reduce the power if the difference is too large. If there is a too large difference of the RF patterns between two carriers (e.g. due to big difference in tilt angles between cells) it will cause a higher rate. The radio coverage should be checked between the carriers. Improper inter-frequency cell re-selection parameter setting can also cause a high rate of RRC Connection directions. The interfrequency cell reselection parameters (e.g. interfreqfddmeasindicator, qhyst2, qoffset2sn and sinterseach) should be checked so that they are set properly. If not, correct them. Improper capacity management parameter setting will also cause a high rate. Check if capacity management parameters (i.e. maximumtransmissionpower and pwradm) are set correctly because they affect the decision of redirection. If not, correct them. Other parameters that should be checked are fachmeasoccacyclencoeff, qqualmin, qrxlevmin, maxtxpowerul, Incorrect definition of a target cell candidate will increase the ratio. If the coverage of target cell candidate collocates to the source cell. If not, remove this candidate, loadsharingcandidate. Repeaters can also cause incorrect RRC connection redirection to a carrier, which is no coverage. LZT R1C 2006 Ericsson

94 Directed Retry to GSM Speech calls with no ongoing packet connections are considered for Directed Retry during RAB establishment. If the UE supports GSM handover and the load of the WCDMA cell exceeds a certain threshold, the WCDMA RAN will request a blind inter-rat handover to a pre-configured GSM cell via the core network. The RAN operator has considerable control over this feature. Both the load threshold and the fraction of speech calls to be diverted to GSM are configurable. The success rate can be monitored by two counters: pmnodirretryatt gives the total number of Directed Retry attempts and the pmnodirretrysuccess gives the number of successful attempts. The failures can be observed by the successful rate of directed retry to GSM for a cell: pmnodirretrysuccess 100% pmnodirectedretryatt Note that unsuccessful attempts are picked up by the WCDMA RAN if the call returns to the source cell. The call will then be set up according to the normal call-setup procedure. If the GSM cell is congested, another TRU can be added or remove the GSM redirection candidate. The loadsharinggsmthreshold can be increased or loadsharinggsmfraction can be reduced so that not many speech connections are redirected to GSM. There might be GSM coverage problems due to low coverage or to that, a repeater is deployed for the WCDMA resource cell. Either the coverage for the cell should be improved or the GSM redirection candidate should be removed. Relative parameter: directedretrytarget, Note that RRC connection rejection caused by inter-frequency load sharing or re-direction of emergency calls to GSM is not considered as RRC connection setup failure Ericsson 2006 LZT R1C

95 3 Service Accessibility RADIO LINK SETUP Radio link setup happens when establishing RRC connection or a RAB during FACH -> DCH, e.g. FACH -> PS + voice or FACH -> PS + PS streaming. The channel type up-switching during channel switching, also needs radio link setup procedure. UE RBS RNC Radio link setup Radio Link Setup Request Power control, admission control, etc. Resource allocation Radio Link Setup Response AAL2 connection setup Start Rx and radio connection supervision Figure 3-21 Radio link setup procedures There is no statistic counter to directly present that radio link setup failure problem during RAB establishment. What that can be done is to analyze the admission control and code allocation counters to determine the probability of occurring such problem. Radio link synchronization happens during RRC connection establishment. The radio link synchronizations also takes place during new RAB establishment, such as channel type up-switching, for FACH -> DCH, e.g. FACH -> PS + voice or FACH -> PS + PS streaming UE RBS RNC Radio link synchronization Transport channel synch. Start Tx L1 synch. Radio Link Restore Indication Figure 3-22 Radio link synchronization procedures LZT R1C 2006 Ericsson

96 Radio link synchronization procedure happens both during RRC connection establishment but also during RAB establishment. (Cell) pmtotnoutranrejrrcconnreq (Cell) pmnofailedafteradm + AAL2 failure AAL2 Setup OK RNC sends the message RRC Connection Setup RNC sends the message RRC Connection Reject No RRC Connection Setup Complete received Call Redirected to GSM Yes Redirection of Emergency Calls? No No Yes Restore Indication received from RBS (Cell)pmNoCellDchDisconnectAbnorm + RRC Conn. Setup Failure. UE goes back to idle state (Cell)pmNoFailedAfterAdm + Yes (Cell) pmtotnorrcconnectreqsuccess + (Cell) pmtotnorrcconnectreqcssuc + Figure 3-23 Radio Link setup counter flow, continued from the Random Access flow figure Figure 3-7 Loss of RBS Contact L1 Synchronization failure RNC sends radio link setup request to RBS; however, the RNC does not receive any response from RBS and the timer expires. This problem is classified as loss of RBS contact. The solution to this problem is to check if the configuration of the transport network is correct. Re-dimension the transmission bandwidth (if needed). It is very difficult to trouble-shoot the radio link synchronization failure. With L1 Synchronization failure, the RRC Setup will fail for the Location Area Update (LAU), as an example Ericsson 2006 LZT R1C

97 3 Service Accessibility The L1 synchronization has to be achieved in both DL and UL. To achieve this, correct power settings are needed for DlinitSirTarget and UlInitSirTarget. The synchronization is first achieved in the DL. The UE will then wait SRBdelay number of frames (1 to 7) before it sends the RRC Connection Setup Complete message. If this fails, no RRC Connection Setup Complete is received from the UE and the RRC Connection is not established. In TEMS, the L1 synchronization problems can be found when the UE does not send the RRC Connection Setup Complete message. However, some other problems may occur at the same time, as the UE ramps up its transmitting power to the maximum, due to the increased interference. The UE ramps up its power to the maximum. Figure 3-24 L1 synchronization problem There are several methods to handle these L1 synchronization failure caused due to coverage issues on SRB and/or DCH, to drive test, check the parameter settings of dlattenuation and ulattenuation as well as the antenna configuration. The main thin is to find out if the system is balanced regarding UL and DL cell coverage. LZT R1C 2006 Ericsson

98 Note that if antenna configuration and attenuation settings are incorrect, the impact should be in RRC establishments for both signaling and traffic. The parameters cpo and cbackoff can also be increased in order to obtain larger initial DL DPDCH and UL DPCCH powers. The DL SRB / DCH maximum power, i.e. minpwrmax (only for DL coverage issue) can be increased and the CPICH power can be reduced in order to get a system that is more balanced. In TEMS Investigation Radio Link Synchronization, failure can be visualized by the figure below. Figure 3-25 Radio Link Synchronization failure In the AS, there are two SC s, RF conditions become very good for one of them and bad for the other, UE TX power is low. It is assumed that the good radio link is out of synchronization because the DL BLER is increasing while the RF conditions become better for one SC. Finally the call drops because high DL BLER. The initial power setup power parameters ulinitsirtargetsrb, ulinitsirtargetlow, ulinitsirtargethigh, dlinitsirtarget, should be checked Ericsson 2006 LZT R1C

99 3 Service Accessibility S-CCPCH (FACH1) power No of AICH_ACK - No of Due to lack of S-CCPCH power, the UE cannot receive the RRC connection setup message. The following formula should only be used if drive tests have been performed in order to verify the S-CCPCH power. Percentage of getting AICH but no RRC connection setup, excluding cell (re)selection: RRC connection setup - No of cell (re)selection during RRC establishment 100% No of AICH_ACK Note that above observations cannot absolutely reflect not enough S-CCPCH power because losing preamble message could affect the result. As an example of an AICH problem can be found in TEMS Investigation. 6 RRC Connection request Very good RF conditions Figure 3-26 Radio Link setup failure: AICH problem in TEMS Investigation LZT R1C 2006 Ericsson

100 NAS PROCEDURES CM SERVICE REJECT The UE sends out several RRC Connection request but it does not receive the RRC Connection setup from the UTRAN. The RF conditions could be fairly. The UE does not get the AICH. It can be seen in the Random access reports, in the mode reports window. One solution to the problem is to increase maxfach1power. The Signaling Connection is used to carry the Non Access Stratum (NAS) call setup message between the CN and UE. The setup of the first Signaling Connection is followed by the procedure Report of Common ID where a permanent NAS UE identity is received by the SRNC from the CN. The permanent NAS UE identity is really the IMSI. The establishment is initiated by the reception of a RRC message that contains the NAS message that originally triggered the Signaling Connection setup. Most of the faults regarding the NAS procedures are core network problems and are therefore not discussed further. During the call setup procedure, the UE receives the CM service reject message with cause network failure, just after that, the system sends the RRC Connection release message Ericsson 2006 LZT R1C

101 3 Service Accessibility CM Service reject with cause: Network failure RADIO BEARER SETUP Figure 3-27 NAS failure: CM service reject in TEMS Investigation This is not an RF problem, is a network problem The RAB establishment is done in two parts, the first is the setup of an Iu bearer and the second is the setup of the Radio Bearer (RB). The establishment and the mapping onto physical channels for each of the different supported RABs will be explained below. In Figure 3-28 the general procedure of establishing a speech, a CS64 or a streaming 57.6 RAB is shown. LZT R1C 2006 Ericsson

102 UE State SRB Cell_DCH DPDCH/DPCCH DPDCH/DPCCH Signaling Connection Non Access Stratum call setup UE State SPEECH Cell_DCH Setup new Radio Bearer DPDCH/DPCCH 3 New Signaling Connection User plane Radio Bearer RAB assignment request id= Speech,CS64 or streaming 57.6 Setup Iu bearer (AAL2) 1 2 DPDCH/DPCCH Figure 3-28 Speech, CS 64, Streaming 57.6 RAB establishment 1. A RAB ASSIGNMENT REQUEST is received from the CN indicating the RAB ID to be speech. The SRNC determines the new RC configuration (taking into account the existing one) and check the UE capabilities (to check if the new configuration can be supported by the UE). 2. The SRNC initiates the setup of an AAL2 connection for the Iu bearer. 3. The UE is ordered to setup a new Radio Bearer (RB) and activate the new configuration at the desired Current Frame Number (CFN). In the SRNC the MAC shall be reconfigured without waiting for the RLC acknowledge. When finished the UE acknowledges the successful RB setup and the UE will be in CELL_DCH state. The interactive PS RAB can be set up on either a common or a dedicated channel. The streaming RAB must be setup on dedicated channel. The steps taken to establish an Interactive PS RAB are shown in Figure 3-29 below Ericsson 2006 LZT R1C

103 3 Service Accessibility UE State SRB Cell_DCH DPDCH/DPCCH DPDCH/DPCCH Signaling Connection Non Access Stratum call setup UE State Cell_FACH or Cell_DCH Setup new Radio Bearer FACH/DCH 3 New Signaling Connection User plane Radio Bearer RACH/DCH Data Buffers RAB assignment request id= Interactive Existing AAL5 Iu bearer is used 1 2 Figure 3-29 Interactive RAB Establishment 1. A RAB ASSIGNMENT REQUEST is received from the CN indicating the RAB ID to be interactive. The SRNC determines the new RC configuration (taking into account the existing one) and check the UE capabilities (to check if the new configuration can be supported by the UE). 2. The existing AAL5 signaling Iu bearer is used to carry the user plane traffic. 3. The UE is ordered by the SRNC to set up a new RB. In the case of Cell_FACH, the UE will also perform a Cell Update after the RB is set up. Data buffers are used for retransmissions and packet data. LZT R1C 2006 Ericsson

104 The RRC has been established and the UE sends the Activate PDP Context Request message to the system. The Radio Bearer Setup message in the DL is never sent, the network eventually sends, and Activate PDP Context Reject message with cause unspecified. Act. PDP Cont. Req. Sent RRC Established Radio Bearer Setup Message never sent PDP Context Activation Failure Figure 3-30 PDP Context Activation Failure. Cause: Radio Bearer Setup not sent Ericsson 2006 LZT R1C

105 3 Service Accessibility The RRC has been established and the UE sends the Activate PDP Context Request message to the system. The Radio Bearer setup and Radio Bearer Reconfiguration are performed. The Downlink Direct Transfer message is sent to the UE followed by an Activate PDP Context Reject message with cause User authentication failed. Radio Bearer Setup Complete User authentication failed Figure 31: PDP Context Activation Failure. Cause: User Authentication Failed UE CELL RESELECTION DURING HANDOVER Accuracy to reflect the connection setup failure issue by call setup failures could be affected due to handover. Actually, these equations contain two components: RRC establishment successful rate and RAB establishment successful rate. For RRC establishment, UE camps onto one cell only. Oppositely, UE could be in soft or softer handover during RAB establishment and the RAB attempt and success counters are just stepped referred to the best cell in the active set. Thus, if the cell camped for RRC establishment is not the best cell in active set during RAB establishment these equations cannot reflect the actual setup problem for the cell. LZT R1C 2006 Ericsson

106 The UE has no time to HO to the best server Attempt to SC122, but SC267 is the best server UE CELL RESELECTION Figure 3-32 UE Cell reselection during handover The UE makes a call attempt to a SC that is not the best server and later it does not have time make the HO because the Ec/No are very bad. This is a cell reselection problem because the UE should make the attempt to the best cell. The RRC connection can fail if the UE does the cell reselection too often. Possible reason of having always cell reselections is idle ping-pong, which may be caused due to improper cell reselection parameter setting and/or pilot pollution The UE sends only one RRC Connection Request and does not receive the RRC Connection setup from the UTRAN. Immediately after this, the UE starts to read SIB. RF conditions are good. It is a UE problem because the UE does not re-transmit the RRC Connection Request Ericsson 2006 LZT R1C

107 3 Service Accessibility Good RF Conditions Only one RRC Connection Request and the UE reads SIB Figure 3-33 UE Cell Reselection Note that the UE may perform cell re-selection during RRC Connection, it may repeat RRC Connection Request message N300 times which may arrive at different cell, and the fact that WCDMA RAN does not double count the duplicated RRC Connection Request message, there is a chance that access success rate for some cells may show larger than 100% success rate. The access success rate of better than 100% happens when the attempt registered at different cell than where the success registered. The end result is slightly larger success rate for the cell that completes the access and a slightly less success rate for the cell that starts the access. Normally, treselection will affect UL RSSI performance because if the UE camps onto a cell, which is not the best cell, the UE will transmit slight larger UE TX power during RRC establishment and it will consequently generate more UL RSSI to the adjacent cells. To solve the reselection problem, the pilot pollution has to be reduced and re-plan the cell coverage if needed. The cell reselection parameters (i.e. qqualmin, qrxlevmin, maxtxpowerul, qhyst2, qoffset2sn, treselection and sintraseach) must be checked if they are set properly. LZT R1C 2006 Ericsson

108 TEMS INVESTIGATION FINDINGS PDP REJECTED Below in the following sections there are several different problems found with TEMS Investigation in a WCDMA network. The RRC has been established and the UE sends the Activate PDP Context Request message to the system. The Radio Bearer setup and Radio Bearer Reconfiguration are performed. The Downlink Direct Transfer message is sent to the UE followed by an Activate PDP Context Reject message with cause unspecified. Radio Bearer Setup Complete Activation rejected, unspecified Figure 3-34 PDP Context Activation Failure. Cause: Radio Bearer setup then PDP rejected PPP LINK CONTROL TERMINATED The RRC has been established and the UE sends the Activate PDP Context Request message to the system. A Downlink Direct Transfer message is sent to the UE followed by the Activate PDP Context Reject one with cause The PPP link control terminated Ericsson 2006 LZT R1C

109 3 Service Accessibility Radio Bearer Setup Not Sent Activate PDP Context Reject after DL Direct Transfer Figure 3-35 PDP Context Activation Failure. Cause: PPP Link Control terminated LZT R1C 2006 Ericsson

110 Intentionally Blank Ericsson 2006 LZT R1C

111 4 Service Retainability 4 Service Retainability Objectives Upon completion of this chapter, the student will be able to: Understand how to analyze and interpret the collected data in order to improve the Neighbor handling and the Hanover Performance Analyze RAN performance and propose adjustments related to retainability LZT R1C 2006 Ericsson

112 Intentionally Blank Ericsson 2006 LZT R1C

113 4 Service Retainability RETAINIBILITY RETAINABILITY WORKFLOW WORST CELLS SPEECH VIDEO PACKET SWITCHED DATA DROPPED CALLS UL OUT OF SYNCH CONGESTION WCDMA RAN HANDOVER SOFT/SOFTER HANDOVER HSDPA MOBILITY INTER-FREQUENCY HANDOVER INTER-RAT HANDOVER MISSING NEIGHBOUR RELATIONS OTHER REASONS WNCS (WCDMA NEIGHBOURING CELL SUPPORT) TEMS INVESTIGATION FINDINGS LOSS OF ASU COMPLETE OR MEASUREMENT REPORTS INTER-RNC HANDOVER FAILURE UE RELATED PROBLEM LZT R1C 2006 Ericsson

114 Intentionally Blank Ericsson 2006 LZT R1C

115 4 Service Retainability RETAINIBILITY This module is done after the accessibility module. Retainability is defined as the ability of a user to retain its requested service once connected for the desired duration. There are a number of factors that influence Retainability performance after call establishment in the network. These factors include: Handover performance (soft/softer/iur/ifho/irat) and missing neighbor cell UL/DL imbalance Incorrect parameter settings (power, admission, release) Congestion Radio environment impact (corner effect, fast Ec/No drop, Pilot pollution etc) Node Hardware failure E1/T1 Congestion RETAINABILITY WORKFLOW Below the Figure 3-2 is showing the Retainability workflow. At performance monitoring the worst cells regarding retainability is sorted out. At performance analysis the worst cells are analyzed in the same order as shown in the Figure 4-2, the network initiated abnormal call releases. First the Synchronization performance is analyzed, then the Congestion control, SHO functions, IRAT Handovers Through the Recommendation and Implementation phase parameters will be looked upon in order to make a change of the networks performance. Through the Verification phase, the collected statistics before anything is implemented is compared to the statistics collected after the implementation is done. This is to ensure that there has been an improvement. LZT R1C 2006 Ericsson

116 Performance Measurements pmsystemrabrelease<rab> pmnormalrabrelease<rab> pmnosysrelspeechulsynch pmnooftermspeechcong pmnosysrelspeechsoho Performance Analysis Recommendation & Implementation ReleaseConnOffset maxtxpowerul,sirmax, MinPwrRl, treselection, timetotrigger1, reportingrange1 Verification of changes Other Modules UL out of Synch Congestion control, SHO functions IFHO functions IRAT Handovers Figure 4-1 A The Retainability workflow At the end of the workflow, when the verification of the implemented changes is done, then the optimizer should continue to the other modules, in this case the integrity module. WORST CELLS In terms of the ranking of the worst performing cell, both the number of drop calls and the dropped call rate should be considered. Alternatively, ranking can be done based on the net contribution of each individual cell to the total dropped call on RNC level. Check where worst performing cells are located. If they are in border area between two RNCs, Iur handover performance should be monitored. In order to identify the worst performing cells due to dropped call the following formulas could be used. SPEECH Shows speech call drop rate for originating and terminating calls. 100 pmnosystemrab Re leasespeech ( pmnonormalrab Re leasespeech + pmnosystemrab Re leasespeecch ) VIDEO Shows video call drop rate for originating and terminating calls Ericsson 2006 LZT R1C

117 4 Service Retainability pmnosystemrabreleasecs ( pmnonormalrab Re leasecs64 + pmnosystemrabreleasecs64 ) PACKET SWITCHED DATA Shows dropped call for Interactive PS calls regardless of DCH or FACH state including HSDPA calls: ( pmnosystemrabreleasepacket ) 100 ( pmnonormalrab ReleasePacket + pmnosystemrabreleasepacket ) 100 Shows dropped call for PS 64 streaming calls. pmnosystemrab ReleasePacketStream ( pmnonormalrab ReleasePacketStream + pmnosystemrab ReleasePacketStream) DROPPED CALLS There are several known reasons for speech drop that can be analyzed in order to understand the root causes for drop and find out how to reduce drop call due to these reasons. 1- Drop due to UL out of sync (Radio Connection supervision) 2- Drop due to congestion (Congestion control) 3- Drop due to soft/softer handover (Soft Handover Functions) 4- Drop due to IRAT Handovers (IRAT Handover Functions) 5- Drop due to other reasons Abnormal call releases for speech, CS64 and CS 57 calls can be initiated either by the UE or by the UTRAN (RNC). For speech, CS64 and CS57 calls the abnormal release leads in any case to the Signaling Connection Release procedure in the counter flow charts. The Signaling Connection Release is the release of the connection of the UE with the CN; it includes the release of all radio resources (RRC Connection Release). LZT R1C 2006 Ericsson

118 In Figure 4-2 the network initiated abnormal call releases are shown. Any abnormal release due to RNC algorithms (Radio Connection Supervision, Congestion Control, Soft-Handover functions, IRAT Handover Functions) or other unrecoverable failures (signaling failures, detected UE failures, etc) are contained in this group. UL OUT OF SYNCH Figure 4-2 Network Initiated abnormal call releases The Other Failures Detected blocks collecting any other unrecoverable failures, those are not included by the first line blocks. These failures will not be further investigated in this document since there are no counters related. Some specific information about these failures can be obtained by the cause of the Iu Release Request or the Iu Release Command messages sent in the Signaling Connection Release or by other specific trace in the RNC and/or CN. Out of synch drops are found through the function Radio connection supervision. The aim of this function is to monitor the status of the radio connection and to initiate the release of signaling connection in case of radio connection is lost. Three different supervision algorithms can trigger the condition of radio connection lost : Ericsson 2006 LZT R1C

119 4 Service Retainability Supervision of radio link synchronization status Supervision of RLC protocol (Layer 2 failures) Supervision of connections on common channels The supervision of radio link synchronization status is performed on dedicated channels only. The supervision of RLC protocol is performed on all channels (dedicated and common). The supervision of connection on common channels is performed (obviously) only on common channel. The RLC supervision works in parallel with the others. One of the other reasons for dropped call is drop due to uplink out of synch. Out of synch is a symptom for other problems such as lack of DL coverage, lack of UL coverage, high UL interference and etc in the network. There is no straightforward approach to identify reasons behind out of synch problem. However, it is still possible to try the following methods to find lack of coverage. Figure 4-3 Radio Link Set Supervision States Idle state is the default state and entered after a dedicated RLS Release. Resources for dedicated RLS have not been allocated or configured. LZT R1C 2006 Ericsson

120 Initial Synchronization state is entered when the resource for the dedicated RLS is allocated and configured, but synchronization has not yet been reached. This state can only be entered from the idle state In sync state is entered when the UL synchronization is achieved from the Initial Synchronization, Out-of-Sync state, or Wait for In- Sync. When the BER is below the threshold value for a number of consecutive frames, the RLS is considered re-established. The RBS resumes regulating the output power according to the Power Control mode Wait for In-sync is a state where the criteria for out of sync has been met. The RBS starts a timer (timerlost) in order to wait for the synchronization to be re-established. Whenever the RLS becomes synchronized, this timer is stopped. If the RBS does not re-establish UL synchronization during the period of time given by the timer timerlost, the "Out-of-Sync" state is entered and the RLS Supervision algorithm sends the NBAP message RADIO LINK FAILURE INDICATION to the SRNC. Out-of-Sync state is entered when the UL synchronization is lost. When the pilot BER threshold value has been exceeded for a number of consecutive frames, the RLS is considered out of sync. When noutsyncind number of consecutive frames are out-of-sync a timer rlfailuret is started and at expiry the RLS is considered out-of-sync and Radio Link Failure is reported to the SRNC. When the RLS is out-ofsync and ninsyncind number of frames are in-sync, the RLS is considered in-sync and Radio Link Restore is reported to the SRNC. The connection is considered lost by the RCS when the last RLS, for the connection, has been out-of-sync for a time given by the parameter dchrclostt. However, for an HSDPA connection, the connection is considered lost by the RCS when the RLS that contains the Serving HS- DSCH cell, has been out-of-sync for a time given by the parameter hsdschrclostt, the timer dchrclostt is not used in this case. In both cases, when the timer expires, the signalling connection is released. The RNC level parameter hsdschrclostt can be set to a lower value than default so that the HSDPA performance does not degrade drastically before the connection is released. This can be a way of tuning HSDPA borders (Iur or when entering a non-hsdpa coverage area), where the HSDPA call is released and re-established on either HSDPA or R99. The RBS, in order to retain synchronization, generates UL-TPC bits in a pattern that gradually increases the output power. TPC received in UL (DL-TPC) are not used Ericsson 2006 LZT R1C

121 4 Service Retainability Shows fraction of drop due to uplink Out of Sync reason. 100 ( pmnosys Re lspeechulsynch) ( pmnonormalrab Re leasespeech + pmnosystemrab Re leasespeech) The amount of dropped call due to UL out of synch is depended on the value of ReleaseConnOffset parameter. If this parameter is set high, then the uplink RSSI will increase and will impact drop due to uplink Out of Sync. There are a number of parameters that impact in- and out of synch issues. These parameters could be of interest when study out of synch and its impact. Changing parameters such as ninsyncind, noutsyncind and rlfailuret might help to recover out of synch when it lasts for short period of time and it not caused due to lack of coverage. In TEMS Investigation, the problem of UL out of Synch can be found through high UE TX power. In soft handover, the UE connects to a distant cell in the active set and this distant cell is the best serving in active set. CPICH_RSCP CPICH_Ec/No Cell A Overshooting cell, e.g. cell UE Tx PWR HO area HO area Tim Max allowed UE Tx PWR HO area HO area Tim Drop Figure 4-4 UE TX Power vs. CPICH Ec/No and RSCP LZT R1C 2006 Ericsson

122 The trend of UL performance of the best serving cell is very good, e.g. CPICH_RSCP is increasing. However, the UE is always requested to transmit its maximum transmission power. When all other cells have been released and only that distant cell is kept in the active set, the connection will drop due to UL out of synchronization. It should be noted that UTRAN sends rrcconnectionrelease message with cause = normalevent to the UE to release the connection if UL out of synchronization. This problem is caused due to cell overshooting. The direct solution is to remove the coverage caused by this overshooting cell Increasing the RBS search window size could overcome this problem. However, it is not good solution because overshooting will cause interference (i.e. lower capacity) and handover sequence problem. Dropping the connection implies the RBS really receives not enough power. Thus, it always sends power up TPC commands. In the measurement report the timing from the RBS is quite high Ericsson 2006 LZT R1C

123 4 Service Retainability Figure 4-5 UL out of synch Downlink supervision is carried out by a similar supervision function located in the UE. The control time constant for the Radio Connection Supervision algorithm must be set longer in WCDMA RAN than in the UE (cchwaitcut > t305), to allow the UE to have time to detect failure and try to restore radio connectivity. UL Coverage Check the value of maxtxpowerul and sirmax parameters. maxtxpowerul parameter should be set based on the most used mobile class type in the network and sirmax parameter should be set to its maximum value (17.3 db). These two parameters have impact on uplink coverage. Low setting of maxtxpowerul and sirmax parameters will limit UE to transmit enough power when it needed to maintain the radio link connection and might cause lack of uplink coverage in the network. Note that bad performing UEs in situation when the coverage gets poor might rapidly increase SIR target and consequently gives spikes in uplink RSSI. Setting sirmax on maximum value might contribute to increase of uplink RSSI for this kind of UEs. sirmax is a RNC level parameter. A very high setting of this parameter might cause increase in UL RSSI where bad performing UEs increase rapidly their SIR target to the maximum allowed SIR target or where UEs get into very poor radio coverage area and increase their SIR target to compensate lack of coverage (anti windup function can not control this type of UE behavior). Out of uplink coverage may be caused not only by low CPICH_RSCP but also by high UL_RSSI. In TEMS Investigation the symptoms of poor UL coverage (i.e. CPICH_RSCP < - 100dBm) is that the DL performance could be either good or bad (i.e. CPICH_Ec/No = any value). The UE always ramps up its power to maximum from a very low calculated initial UE Tx power. Due to this UL poor coverage issue, even the UE ramps up its power to maximum, the network still cannot receive request message. LZT R1C 2006 Ericsson

124 UTRAN sends rrcconnectionrelease message with cause = normalevent to the UE to release the connection. The UE ramps up its power to max from a very low calculated initial UE Tx power. The network can t receive request messages. Figure 4-6 UL/DL Imbalance After a while, the UTRAN normally sends the rrcconnectionrelease message with cause = normalevent to the UE to release the connection. One of the timers that are checking the RL supervision, the rlfailuret, times out. The UL and DL coverage imbalance can be solved by reducing the pilot power. Often by turning the pilot power down there will be a coverage hole and in the end a new site has to be added. Imbalance will cause Inner loop power control problems to due UE ray combining inefficiency and UL easy become Out-Of-Synch Ericsson 2006 LZT R1C

125 4 Service Retainability By using GPEH event INTERNAL_MEASUREMENT_HANDLING_ EVALUATION it is possible to get number of times event6a is reported. Event6a shows maximum transmitted power reported from UE based on the value of uetxpowerthresh6a parameter in best serving cell. If uetxpowerthresh6a parameter is set to 21 and event6a is reported in GPEH, then there is a risk for end-users to be located in area with lack of coverage in the concerned cell. DL Coverage The following approach might be used to give some indications about lack of downlink coverage. By using GPEH events: INTERNAL_MEASUREMENT_HANDLING_ EVALUATION it is possible to get number of times event2d is reported. Event2d shows how bad measured pilot Ec/No is in best serving cell. INTERNAL_RADIO_QUALITY_MEASUREMENT it is possible to get downlink code power per call basis. This power reporting is not so frequently but it still gives indications on used code power on downlink. For cases where GPEH trace shows high code power usage close to max power available on concerned RAB, it is a good indication of lack of downlink coverage in recording cells. If the conclusion is that there is lack of downlink coverage, maximum allowed downlink code power on relevant RAB should be increased for concerned cells UL RSSI High uplink RSSI will influence uplink radio quality and increase risk of getting into out of synch problem. MinPwrRl is a cell level parameter. This parameter impacts uplink RSSI and should not be set less than 150. Other setting such as 120 can be tested to see how much uplink RSSI will be reduced. At the same time total carrier power should be monitored to see eventual increase in power consumption when changing minpwrrl parameter. A trade off can be done to see drop call or uplink RSSI reduction in relation to eventual carrier power increase for concerned cells. LZT R1C 2006 Ericsson

126 CONGESTION For the worst performing cells a number of RBS counters such as pmaveragerssi, pmtransmittedcarrierpower and pmoutofsynch can be activated before changing minpwrrl parameter to monitor the performance of worst performing cells. A reason for dropped call seen through statistic is congestion. If any portion of drop caused by congestion it will mean that more HW is needed for RBS based band pool capacity. Shows fraction of speech drop due to congestion action 100 ( pmnooftermspeechcong) ( pmnonormalrab Re leasespeech + pmnosystemrab Re leasespeech) Shows fraction of video call drop due to congestion action ( pmnooftermcscong) 100 ( pmnonormalrab Re leasecs64 + pmnosystemrab Re leasecs64) Congestion control is used to resolve overload in the uplink and the downlink. It uses Power and uplink Received Total Wideband Power (RTWP) measurements. In case of overload, congestion control reduces bit rates of delay tolerant existing connections or as a second option, removes existing connections. The threshold for detection of downlink congestion is determined by pwradm + pwradmoffset + pwroffset and the Hysteresis time pwrhyst. Congestion due to radio overload in uplink is detected when the uplink Received Total Wideband Power (RWTP) exceeds a certain configurable threshold for a longer time than the Hysteresis time. The threshold for detection of uplink congestion is determined by ifcong + ifoffset and the Hysteresis time is determined by ifhyst. Congestion Control considers uplink congestion to be resolved when the uplink RTWP for a particular cell is below ifcong for a longer time than the Hysteresis time (or until the next periodic event-based measurement report for uplink RTWP arrives indicating that the resource level is below the threshold) Ericsson 2006 LZT R1C

127 4 Service Retainability The parameter pwrhyst should cope with short length peaks in the downlink transmitted carrier power that in general do not lead to downlink cell congestion situations, so that unnecessary blocking of the cell and (even worse) unnecessary congestion resolve actions are avoided. Field tests have shown that the default setting is acceptable in most cases. Nevertheless, pwrhyst can be modified depending on the duration of the peaks in the downlink transmitted carrier power, which may be influenced by the UE behavior, radio environment and power control settings. The detection level for uplink cell congestion is determined by ifcong + ifoffset and by the Hysteresis time setting ifhyst. In general, the expected level of uplink Received Total Wideband Power (RTWP) is formed by the sum of the following components: Thermal noise floor (for example, dbm) RBS noise figure (typically 2 db with Ericsson ASC/TMA or 3 db without ASC/TMA) Noise rise due to load (60% loading in uplink corresponds to 4 db) Compensation for innacuracies in Radio Network algorithms (around 2 db) Detection of uplink cell congestion could be on a level which is around 2 db extra noise rise (parameter ifcong). By default, the uplink cell congestion detection is disabled by setting ifcong to dbm, ifoffset to 0 and ifhyst to 10 ms. In many networks, UL interference is not the main limitation and this setting is acceptable in most cases. If there is a high degree of uplink interference in a cell, it can be relevant to tune these parameters to resolve excessive cell breathing. When setting the parameter ifhyst, short duration UL interference peaks should be disregarded as, in general, they do not lead to uplink cell congestion. Unnecessary detection of uplink congestion leads to unnecessary blocking of the cell. Field tests have shown that there might be special conditions in a cell or specific UE behaviors that may require this parameter to be tuned. Another reason for dropped call seen through statistic is congestion. If any portion of drop caused by congestion it will mean that more HW is needed for RBS based band pool capacity. LZT R1C 2006 Ericsson

128 This can also be monitored by using for instance RBS counters such as pmsetupfailuressf128 in downlink and pmsetupfailuressf64 in uplink for speech calls to identify capacity shortage in downlink or uplink based band pool. Other counters that should be checked if the drop rate due to high congestion is listed in the table below: Counter name Function Description pmnoreqdeniedadm pmnooftermspeechcong RRC request and RAB establishment deny Speech call termination The counter shows the number of RRC connection requests and RAB establishment denied by admission control due to lack of power, code utilization limit, ASE limit and compressed mode limit. The counter shows the number of times speech call terminated due to cell congestion pmnooftermcscong pmtotaltimedlcellcong pmtotaltimeulcellcong PmSumOfTimesMeasO1D1 pmnoofswdownngcong pmnoofswdownngadm Cs call termination DL Cell Congestion Duration UL Cell Congestion Duration Magnitude of High DL Power Down switch from DCH to common channel due to congestion control Down switch from DCH to DCH due to admission control The counter shows the number of times CS call (excluding speech) terminated due to cell congestion It shows amount of time in seconds during the measurement period that cell was congested in DL It shows amount of time in seconds during the measurement period that cell was congested in UL It shows number of times congestion control is triggered due to high DL carrier power The counter shows number of times packet data connection down switches to common channel initiated by congestion control. If the down switch is not allowed to common, then the counter shows number of packet data system release due to congestion The counter shows number of times packet data connection down switches from DCH 64/384 to DCH 64/128 and DCH 64/128 to DCH 64/64 initiated by admission control due to lack of downlink power or code limit Ericsson 2006 LZT R1C

129 4 Service Retainability WCDMA RAN HANDOVER There are four types of handover supported in the WCDMA RAN: Soft/Softer Handover Inter-Frequency Handover Inter Radio Access Technology (Inter-RAT) handover HS-DSCH Handover In reality a handover drop cause includes due to same trigger points missing neighbor/overshooting. The same triggers are used for both drop reasons. Figure 4-7 Entities Involved in Reporting, Evaluation, and Execution of Handover-Related Functions LZT R1C 2006 Ericsson

130 SOFT/SOFTER HANDOVER The soft/softer handover functionality includes decision on how many cell carriers to connect in soft/softer handover and functionality for setting up and releasing connections between the RBS and the UE. Soft/softer handover is supported for dedicated channels. RNC RBS 1 RBS 2 Figure 4-8 Soft Handover In soft handover the UE is communicating with two or more sectors on different RBSs as illustrated in Figure 4-8. In softer handover the UE is communicating with two or more sectors on the same RBS. The counter flow for the cell reselection for Inter-frequency handovers are shown in the Figure Ericsson 2006 LZT R1C

131 4 Service Retainability Intrafrequency Measurement Report Evaluation 1a event including quality measure and cell synch info 1 b event 1c event including quality measure and cell synch info 1d event including quality measure and cell synch info Soft/Softer HO Removal Not valid cell and reported cell exceeds best cell + Rel. Conn. Offset quantity? Yes Yes Not valid cell and reported cell exceeds best cell + Rel. Conn. Offset quantity? No No Soft/Softer HO Addition Soft/Softer HO Replacement Speech call only (Cell) pmnosysrelspeechneighbr + (Cell) pmnosysrelspeechsoho + Yes Not a valid cell? No Abnormal Call Release Best cell Update Figure 4-9 The counter flow for soft/softer handover A valid cell is a cell that is included in the neighbor set. Soft/Softer HO replacement procedure is made up of both Soft/Softer HO addition and removal in sequence. Upon successful Soft/Softer HO replacement the counters pmnotimesrlrepinactset and pmnotimesrldelfractset are incremented for the cell that is removed from the AS and pmnotimesrladdtoactset is stepped in the cell that is added. LZT R1C 2006 Ericsson

132 The first thing to check is to see if any fraction of drop call is related to handover. The following formula shows the fraction of drops due to HO action when a valid or non-valid cell cannot be added to active set. This also includes drops due to missing neighbour. 100 pmnosysrelspeechsoho pmnosystemrabreleasespeech ( + pmnonormalrabreleasespeech) The following formula shows the failure rate for RL addition/replacement to active set 100 pmnotimescellfailaddtoactset pmnotimescellfailaddtoactset ( + pmnotimesrladdtoactset) The UE reselects the new cell, if the cell reselection criteria are fulfilled during the time interval treselection, see Figure Quality qhyst(s) Qmeas(n) R(n) qoffset(s) R(s) Qmeas(s) treselection time Cell reselection Figure 4-10 The cell reselection evaluation process. The cell reselection criteria are used for intra-frequency, interfrequency and inter-rat cells. The decision on when measurements on intra-frequencies should be performed is made by the parameter sintrasearch in relation to Squal Ericsson 2006 LZT R1C

133 4 Service Retainability If Squal > sintrasearch the UE does not need to perform intrafrequency measurements. If Squal sintrasearch the UE performs intrafrequency measurements. If the sintrasearch is not sent to the serving cell, the UE performs intrafrequency measurements. The UE shall measure CPICH Ec/No and CPICH RSCP at least every T MeasureFDD for intra-frequency cells. The UE shall filter Ec/No and RSCP measurements of each measured intra-frequency cell using at least 2 measurements, which are taken so that the time difference between the measurements is at least T MeasureFDD /2.The UE shall evaluate this intra-frequency cell for the treselection time and if it is still better than the serving cell the UE shall reselect that cell. UE Cell reselection The RRC connection can fail if the UE does the cell reselection too often. Possible reason of having always cell reselections is idle ping-pong, which may be caused due to improper cell reselection parameter setting and/or pilot pollution. Areas with many equally strong CPICHs, so-called "pilot pollution areas", should be avoided. Preferably only one dominant CPICH should exist. UEs in pilot-polluted areas may experience unreasonable high Active Set update rates and a higher probability that the Active Set does not at all times contain the most appropriate cells. With extensive pilot pollution in the system the signaling load increases. Pilot pollution gives a high average number of active radio links, which decreases the traffic capacity and reduces the probability that the UE gets all neighboring cells included due to the size limited monitored set. It is recommended to design the system so that the idle mode cell selection/reselection borders coincide with the connected mode HO borders. It is also recommended that the CPICH power setting initially balances the UL and DL in the handover area. A balanced system in this context means that the pathloss is equal at the handover borders for every cell to be included, or are already included in the Active Set. The handover areas and where the handover decisions are taken can be changed by changing CPICH power levels for the cells. LZT R1C 2006 Ericsson

134 The UE sends only one RRC Connection Request and does not receive the RRC Connection setup from the UTRAN. Immediately after this, the UE starts to read SIB. RF conditions are good. It is a UE problem because the UE does not re-transmit the RRC Connection Request. Note that the UE may perform cell re-selection during RRC Connection, it may repeat RRC Connection Request message N300 times which may arrive at different cells, and the fact that WCDMA RAN does not double count the duplicated RRC Connection Request message, there is a chance that access success rate for some cells may show larger than 100% success rate. The access success rate of better than 100% happens when the attempt registered at a different cell than where the success registered. The end result is slightly larger success rate for the cell that completes the access and a slightly less success rate for the cell that starts the access. Normally, treselection will affect UL RSSI performance because if the UE camps onto a cell, which is not the best cell, the UE will transmit slight larger UE TX power during RRC establishment and it will consequently generate more UL RSSI to the adjacent cells. To solve the reselection problem, the pilot pollution has to be reduced and re-plan the cell coverage if needed. The cell reselection parameters (i.e. qqualmin, qrxlevmin, maxtxpowerul, qhyst2, qoffset2sn, treselection and sintraseach) must be checked if they are set properly. In TEMS Investigation the cell reselection problem can be found in many ways. As an example the UE has sent out the rrcconnectionrequest message for access. During the UE is waiting for rrcconnectionsetup message It detects another better (i.e. better CPICH_Ec/No) cell and tries to do a cell re-selection. It happens when the number of rrcconnectionrequest is still less than (N ). When the UE tries to do cell reselection the number of rrcconnectionrequest finally reaches to maximum (i.e. n ). The setting for treselection can be too short. Optimization is needed in order to avoid the idle mode pilot pollution. If the UE does not send out the rrcconnectionrequest after cell reselection., it could be an UE problem, which is not RF related. The table below is showing the rrcconnectionrequest messages together with the scrambling code and the corresponding EcNo value of the example below Ericsson 2006 LZT R1C

135 4 Service Retainability Time Type of message Content 11:26:49.87 rrcconnectionrequest SC=82 CPICH_Ec/No=-4dB 11:26:51.91 rrcconnectionrequest SC=98 CPICH_Ec/No=-8dB 11:26:51.95 rrcconnectionrequest SC=98 CPICH_Ec/No=-8.5dB 11:26:53.94 rrcconnectionrequest SC=98 CPICH_Ec/No=-4.5dB 11:26:55.69 rrcconnectionrequest SC=82 CPICH_Ec/No=-9.5dB Figure 4-11 Cell re-selection was done between SC98 and SC82 LZT R1C 2006 Ericsson

136 Handover parametes The recommended setting of maxactiveset parameter is 3. Increasing the value leads to an increase in the average number of active radio links. The difference will be minor in some areas, whereas in areas with many strong CPICHs, the average number of active radio links will increase considerably. In UL more active radio links on average gives a slightly lower transmitted power. In DL more active radio links gives a lower transmitted power per link, but the sum of transmitted power on active links might not be lower. The number of Active Set updates per minute is dependent on the radio environment and there is no direct relation to the setting of the maxactiveset parameter Figure 4-12 shows the parameters involved with a handover. Figure 4-12 Cell re-selection TimeToTrigger1- and reportingrange1- parameters might be reviewed and other settings than the default (current) setting might be used. Note that these parameters are RNC level parameters and influence the whole RNC. Hence it might not be possible to change these parameters due to negative impact on other cells that handover functions well there Ericsson 2006 LZT R1C

137 4 Service Retainability The size of the soft and softer handover area can be changed by the reportingrange1a and reportingrange1b parameters. The recommended parameter values are 3 db and 5 db, respectively. Increasing reportingrange1a or reportingrange1b results in larger soft/softer handover area, that is, more UEs will be in soft/softer handover on average. The average number of active radio links in the network can grow very large when increasing the value of reportingrange1a and reportingrange1b. Figure 4-13 Field tests with settings of the reportingrange parameters Figure 4-13 shows an example from field measurements. The actual Active Set size has been logged when driving a 10-minute route through a pilot-polluted area. The same route was driven four times, each time with different settings of reportingrange1a and reportingrange1b, but keeping the delta between them constant. maxactiveset was set to 3 during all measurements. As seen in the figure, the distribution of measurement points having different Active Set sizes change gradually. Using reportingrange1a = 3 [db] and reportingrange1b = 5 [db], the average number of cells in the Active Set is expected to have the following distribution: 60% for AS=1, 30% for AS=2, and 10% for AS=3. The highest parameter settings cause the UE to be in soft/softer handover in basically all spots along the route, a situation that is unfavorable for system capacity. LZT R1C 2006 Ericsson

138 The recommended value for hysteresis1c is 1 db. A higher value causes a decreased Active Set update rate, that is, a higher CPICH signal is required from a new cell to replace the weakest cell in Active Set. What would make the Active Set update rate decrease is the reduction of event1c, since event1a and event1b are kept fairly constant. But a higher value of hysteresis1c may cause too late an addition of new cells in Active Set. It is important to remember that the measurements used for handover event evaluation are made on the downlink CPICH. This means that using different settings for primarycpichpower (power assigned to the CPICH) on neighboring cells will create a more complicated situation. Unnecessary destructive interference might be the result in the UL, since the UE will not be power controlled by the weaker cell until it has been added to the Active Set. The UE face problems in areas were many pilots have similar received Ec/No (especially in low RSCP areas). In order to help the UE, the time to trigger for events e1a, e1b and e1c can be raised. However, as stated above, the parameters affect the whole RNC and should be carefully considered. The increase reduces the number of handover attempts, especially for the undesired flashing pilots. It can also lead to a higher drop rate with highways in the area of fast fading. timetotrigger1a indicates the time in ms between event detection and sending of Measurement Report, for event 1a (New candidate cell for addition in Active Set) timetotrigger1b indicates the time in ms between event detection and sending of Measurement Report, for event 1b (Removal of an existing cell in Active Set) timetotrigger1c indicates the time in ms between event detection and sending of Measurement Report, for event 1c (A cell outside Active Set becomes better than a Cell in Active Set) The change of the timetotrigger values have been made in order to avoid ping-pong effect in cell additions and replacements, and possible call drops. For example, if there is a call in Cell A and the signal of it s neighbor Cell B becomes stronger for a moment and at the same time Cell A becomes weaker, Cell B would be added and Cell A would be removed from the active set. If Cell A becomes strong immediately after removal this could interfere the connection and can lead to a drop Ericsson 2006 LZT R1C

139 4 Service Retainability When timetotrigger1a is increased, the signal of the neighbor cell has to be strong for a longer time before making the decision to add it to the active set. This will avoid adding cells that become strong only for a very short time. If we set timetotrigger1b higher than timetotrigger1a we delay the removal of a cell from the Active Set to reduce the probability that fading effect will force the removal of a cell that could become stronger soon after the removal. This should reduce the probability for the drops mentioned above to happen. At the same time timetotrigger1c is set equal to timetotrigger1a to replace weaker cells that are being delayed for removal. Even with the increase of the timetotrigger there is still the possibility that flashing neighbours (far away sites that cannot be added to the neighbour list and cannot be tilted) are being reported for addition by the UE. Whenever the value for one of these cells is higher than the best cell in the active set by an amount equal or greater than ReleaseConnOffset, the connection would be released. The increase of the parameter allows for a greater tolerance on UL interference for a short time in the system before releasing the call. Both the change in timetotrigger and ReleaseConnOffset reduce the probability for this kind of release to happen. Note a high value for ReleaseConnOffset will reduce the capacity in the RBS due to higher interference and affects the HSDPA performance. ReportingInterval1a is the interval of event-triggered periodical reporting in case of cell addition failure or cell replacement failure. Indicates the interval in sec. of periodical reporting, triggered by event 1a ReportingInterval1c is the interval of event-triggered periodical reporting in case of cell addition failure or cell replacement failure. Indicates the interval in sec. of periodical reporting, triggered by event 1c. Both of the timers have been shortened to cope with the increase in the value for the relative timetotrigger. Since the measurement Report is being delayed, it is preferred to send the periodic repetition of the same measurement Report earlier than with the default settings in the event there is no answer from the RNC. Having both a longer timetotrigger and a long ReportingInterval could lead to excessive delays in the handover and possible drops. Too short timetotrigger values will cause mismatch between neighbor set in the UE and the neighbor set in the RNC. LZT R1C 2006 Ericsson

140 Inconsistent neighbor set When the UE is setup on a dedicated channel, during the RRC signaling connection establishment, the SRNC sends a MEASUREMENT CONTROL message, with "setup" indicator to the UE. This message is the first MEASUREMENT CONTROL message the UE receives for this particular connection and it contains the list of cells and the measurement criteria to be used. The list of cells and the measurement criteria for support of Soft/Softer handover are also broadcasted in the system information on the BCCH channel, in SIB11/SIB12. This allows the UE to start Intra frequency measurement on configured neighbors Intra frequency for the cell where the RRC connection was setup before receiving the MEASUREMENT CONTROL message from the SRNC. In TEMS Investigation can be seen that the active set lists in the UTRAN and the UE are inconsistent. As a result, the UE might not connect to the best cell. Then the UE suffers interference from that cell and finally the connection drops. Alternatively, the UE tries to add a better cell into active set; but the UTRAN ignores it because it thinks the cell has been in the active set already. UE RNC Measurement Control Measurement Report Active Set Update Active Set Update Complete Measurement Report Measurement Control Figure 4-14 The Measurement reports and ASU complete can vanish in case of a bad timetotrigger setting Ericsson 2006 LZT R1C

141 4 Service Retainability UE only has two active set cells, SC9 and SC1 UTRAN requests the UE to do replacement handover, i.e. UTRAN thinks the UE has 3 AS cells Figure 4-15 Inconsistent Lists The possible reason for this case can be that the uplink performance is poor. As a result, the sent active set update complete might not be received from the UTRAN; due to this the inconsistent active set problem could happen. The solution is to improve the coverage, e.g. tilting, reducing the pilot power so as to remove the uplink and downlink imbalance issue, etc. It is also recommended to check the timetotrigger parameter settings LZT R1C 2006 Ericsson

142 UE only has two active set cells, SC35 and SC116 Figure 4-16 Inconsistent Lists between UE and RNC UTRAN requests to remove SC148. The UE doesn t have SC148. UE replies with active set update failure. In the figure above the UE is requested to remove SC 148, in the Active Set Update (DL-DCCH) even if the UE only have SC35 and SC 116 in the Active Set. Therefore, the UE replies UTRAN with active set update failure. In another case, the UE sends several measurement reports to propose SC148. However, the UTRAN does not reply the UE Ericsson 2006 LZT R1C

143 4 Service Retainability UE only has one cell in active set cells SC77 Figure 4-17 Removal of incorrect cell Cause: Inconsistent Lists UTRAN requests the UE to remove SC85, which is much better than SC77, while the UE want to remove SC77 In another case, the UE sends a measurement report to propose to remove a cell, see Figure 4-17 and Figure The UTRAN replies the UE with active set update but it requests the UE to remove the best serving cell in the active set. LZT R1C 2006 Ericsson

144 UTRAN requests the UE to remove SC85, which is much better than SC77 UE requests to remove SC77 Figure 4-18 Removal of incorrect cell Cause: Inconsistent Lists After the handover, the UE is connected to a cell with poor CPICH_Ec/No. Then the UE sends many measurement reports to propose to add the better cell back into active set. However, due to poor downlink performance (i.e. pilot channel failure Ec/No ~ - 16dB), maybe the UE cannot receive the active set update message. The area is also having many pilots in the area, which could lead to the problem described above. The first solution to this problem is to make sure the pilot pollution is reduced to the minimum in the network Ericsson 2006 LZT R1C

145 4 Service Retainability Other parameter checks For IndividualOffset parameter verify if other setting than default could improve handover performance for worst performing cells. Keep in mind IndividualOffset is cell based and not cell relationbased parameter which means changes to IndividualOffset parameter can move handover border back or forth in relation to all neighbors and not one specific neighbor. This will limit the usage of this parameter. Check the value of InitShoPowerParam parameter. Settings other than the default can be tested and verified. A lower setting than zero can reduce UL RRSI due to the fact the new radio link starts with lower initial power before it has synchronized. InitShoPowerParam is used in the initial downlink power setting during soft handover. Other things that should be checked are the following 1- Check whether the pilot power of worst performing cells and their neighbors are set equally. More than 1-2 db difference between pilot powers of neighbors might impact call drop. 2- Check the value of releaseconnoffset parameter. A low setting will give more call drop for cases where a reported detected cell is not in RNC neighbor cell list. 3- Investigate how accurately the DL and UL attenuation parameters are set. 4- Neighbor cell offset (serving, neighbor) is used to move the border between cells. qoffset1 and qoffset2 is the offset between the two cells that is read in the system information of the serving cell. In P4 there are now two separate measurements running to detect bad quality, one is using Ec/No, and another is using RSCP. Either of these might trigger, and when one of them does, then the following IF or GSM measurement is started using the same measurement quantity that triggered bad quality. In P3 the parameter qualmeasquantity could be set by the operator in order to measure either on the Ec/No or RSCP LZT R1C 2006 Ericsson

146 Soft Handover Overhead per RAB In order to find to large handover areas in the system and to find out the average number of RL per user the following formula should be used: SHOoverhead= pmsum < RAB > RabEstablish pmsamples < RAB > RabEstablish UtranCell counters pmsumrabestablish pmsamplesrabestablish RNC counters allcells Figure 4-19 Example of different services and their overlapping areas Theoretically the cell overlapping area of high bitrate services (e.g. PS128, PS384) should be reduced compared with low bitrate (Ps64 or speech). It depends on network dimensioning (site to site distance and load). HSDPA MOBILITY There is no Admission Control needed for doing HS-DSCH Cell Change; Admission Control is however needed when HS-DSCH RAB is established. When the UE moves between cells which are HSDPA enabled (that is, when hsdpacapability = HSDPA_CAPABLE), the HSDPA connection is maintained by means of the serving HS-DSCH cell change functionality or, shortly, HS cell change. HS-DSCH Cell Change can be seen as a handover to a dedicated place in a queue to a common channel (HS-DSCH) in a new cell. Note however that HS-DSCH Cell Change can not be performed over Iur Ericsson 2006 LZT R1C

147 4 Service Retainability HS-DSCH Handover event 1d HS-DSCH - IRAT and IFHO HS-DSCH Handover HS-DSCH Cell Change evaluation performs the evaluation of a valid target cell within the current Active Set, if a change of the best cell or a removal of the Serving HS-DSCH has been triggered by the A-DCH Soft Handover evaluation. The Cell Change evaluation is triggered only if the parameter hscellchangeallowed is set to TRUE. HS-DSCH does not use soft handover as the dedicated channels (DCH) do. There is a trade-off between optimizing the radio quality of HS-DSCH (that is, frequent enough cell changes) and minimizing the impact on throughput at cell change (that is, as few cell changes as possible). When the Ue is using HSDPA, the MEASUREMENT CONTROL orders an extra event that supports Serving HS-DSCH Cell Change (event 1 d HS) to be reported by the UE. The reason for having a separate event 1d HS is to be able to get UE reports triggered by only Active Set cells and to be able to use different Hysteresis and time to trigger parameters to trigger HS- DSCH Cell Change. It is also possible to use a different quality criteria than used for the conventional event 1d. The default quality criteria used for the event 1d HS is the CPICH RSCP. The parameter hsqualityestimate indicates whether it is CPICH Ec/No or CPICH RSCP that should be used for indicating "best cell" for HS-DSCH Cell Change. The event 1d HS does not imply any Active Set Update since the change of the best cells triggered by the event 1d HS can be related only to a cell already included in the Active Set. When the Ue is PS Interactive using HSDPA, the MEASUREMENT CONTROL includes only neighbor cells of type intra-frequency and no Compressed Mode is triggered, that means that Inter-Frequency and Inter-RAT Handover are not possible to be performed. When the UE leaves PS Interactive using HSDPA, a full neighbor list is used (as well as Compressed Mode). If the Serving HS-DSCH Cell Change has been disabled by parameter hscellchangeallowed (FALSE) the change of the best cell in the Active Set will not have any effect. On the other hand, LZT R1C 2006 Ericsson

148 the removal of the Serving HS-DSCH cell will trigger an RRC connection release. The call will then be set up on an HSDPA RAB, if the new cell is HSDPA enabled, but it will take longer than if cell change was allowed, leading to a certain throughput degradation. If the best cell is not an HSDPA capable cell and the current HS- DSCH serving cell needs to be removed from AS (that is, an HSDPA coverage border), the connection will be released and automatically re-established by the packet application on R99. If the best cell is not an intra-rnc cell (that is, when the UE moves over Iur) and the current HS-DSCH serving cell needs to be removed from the AS, an RRC connection release with the cause "directed signaling connection re-establishment" is triggered. With this cause value, the call will be immediately setup either on HSDPA or on R99 in the best cell belonging to the new RNC, depending on if the best cell is HSDPA capable or not. In order to avoid releases and setups following a ping-pong pattern, the Iur borders should be carefully defined. HS-DSCH cell change for a 384/HS connection can only take place if the target HS-DSCH cell has UL 384 enabled and 384/HS resources available. If not, the call will be kept until it is released, probably due to an event 1b or to loss of synchronization. The Serving HS-DSCH Cell Change can introduce a delay in the A-DCH Soft and Soft Handover execution in case of a removal of the Serving HS-DSCH has been triggered. In that case the Active Set Update evaluation will trigger a Serving HS-DSCH Cell Change first and then trigger Active Set Update execution Ericsson 2006 LZT R1C

149 4 Service Retainability INTER-FREQUENCY HANDOVER Inter-frequency handover allows an ongoing call to be transferred from one frequency to another in a case where a UE is moving out of coverage of the source frequency. The feature covers functions for both inter-frequency handover for UEs on dedicated channel and for inter-frequency cell re-selection on common channel and in Idle Mode. f 2 f 2 f 1 f 2 f 1 f 1 Figure 4-20 WCDMA Handover (Inter Frequency Handover & Cell Reselection) The IRAT or IFHO functionality can be enabled per cell. When bad connection quality has been triggered, the type of HO to be attempted is configurable per cell. The parameter hotype can be set per cell to GsmPreferred, IfPreferred or to None, and a setting to None means that no IRAT or IFHO can be done from this cell, and compressed mode shall not be started. If for some reason the preferred HO type can not be initiated, then the other HO type might be attempted instead. IRAT and IFHO are both triggered by coverage. The purpose with both functions is to save the connection by making a HO to either GSM or to another WCDMA frequency, when the coverage on the original WCDMA frequency deteriorates. Instead of dropping, the connection should preferably continue on another WCDMA frequency or in GSM. In order to detect deteriorating coverage, the connection quality monitoring uses events 2d and 6a to trigger bad coverage in DL or UL. When either event is triggered, the UE will start new measurements for either IF or GSM cells, to try to detect a new candidate cell to make a HO to. This usually also involves starting compressed mode. LZT R1C 2006 Ericsson

150 IFHO Neighbour list The time required for the UE to detect a new cell varies between approximately 2 to 8 seconds, measured from the detection of bad coverage to detection of the new HO candidate cell. This time depends on signal-levels, the UE measurement performance and the length of the neighbor cell lists. In order to make a reliable HO, instead of dropping the call, the deteriorating coverage must be detected early enough, and the neighbor cell lists should not be longer than necessary. It should be noted that the UE measurement performance might also vary between different manufacturers. The UE can measure on a maximum of 32 IF cells, and on a maximum of two other frequencies. When a second carrier f2 is introduced in clusters as co-located cells, the initial IF (f2 to f1) neighbour list for the f2 cell could be defined by copying the corresponding f1 neighbour list from the co-located f1 cell, and adding the co-located f1 cell. However, if the coverage for the IF cell deteriorates quickly and it is important that the IFHO can be performed fast, then the IF neighbor lists should be as short as possible. The time it takes for a UE to find a candidate IF cell generally increases with longer neighbor cell lists, and keeping the list short should generally lead to less time in compressed mode and better retainability performance. When a second carrier is deployed as a hotspot cell, two-way neighbor cell relationships should be defined only between the under-laying f1 cell and the over-laying f2 cell. One-way neighbor cell relationships are defined from the f2 cell to all the surrounding f1 cells. The main benefits with this setup are the elimination of IFHO from the surrounding f1 cell to the f2 cell, the decreased risk of CPM starts in the f1 layer, and the shorter neighbor lists. With one-way definitions, all surrounding f1 cells become blind to the f2 cell. It should also be noted that the P-CPICH power settings should initially be set to the same values for the f2 cells as for the colocated f1 cells. The f2 to f2 neighbor lists for the second carrier cells could also initially be determined by using the f1 neighbor lists for the corresponding co-located cells Ericsson 2006 LZT R1C

151 4 Service Retainability IFHO Parameter check IFHO Handover Speech The first step is to locate the WCDMA cells which are coverage limited and decide if either GSM HO or IFHO should be enabled in these cells in order to reduce the dropped calls caused by the coverage limitation. For these cells the GSM and/or the IF neighbor cell lists should be defined, keeping the lists short if possible and without defining unnecessary neighbor relations. The next step is to set parameters for the IRAT and IFHO functions. The event 2d threshold can be adjusted per cell, and can be used if an early detection of the coverage problem is necessary in some cells or locations in order to make a successful HO. For example, a cell which has locations where the coverage falls quickly for many users, leading to dropped calls, might need a higher threshold setting for the 2d event. The thresholds 2f, 2b (used frequency) and 3a are relative thresholds to the event 2d and will also be per cell level. The relative parameter values are set on RNC level. The purpose with this procedure is to decrease the amount of coverage generated dropped calls, so that most of these calls instead can continue in GSM or on another WCDMA frequency, but without causing too many false triggers or too many users in compressed mode. Frequent starts and stop of compressed mode always come with a cost in terms of power and HW resources. The dropped calls should be monitored during these procedures, and the total number of drops per cell should be calculated before and after the GSM or IFHO functionality is enabled Drop due to IFHO failure for speech: Outgoing IFHO failure when UE failed to return to present active set. pmfailnonblindinterfreqhofailrevertcsspeech pmattnonblindinterfreqhocsspeech12 The following formula might give slightly lower result: pmfailnonblindinterfreqhofailrevertcsspeech pmsuccnonblindinterfreqhocsspeech12 + pmfailnonblindinterfreqhorevertcsspeech12 + pmfailnonblindinterfreqhofailrevertcsspeech12 Drop due to IFHO failure for CS except speech: Outgoing IFHO failure when UE failed to return to present active set. LZT R1C 2006 Ericsson

152 pmfailnonblindinterfreqhofailrevertcsconversational 100 pmattnonblindinterfreqhocsconversational Drop due to IFHO failure for PS less or equal to 64 kbps: Outgoing IFHO failure when UE failed to return to present active set. pmfailnonblindinterfreqhofailrevertpsinteractiveless pmattnonblindinterfreqhopsinteractiveless64 Drop due to IFHO failure for PS greater than 64 kbps: Outgoing IFHO failure when UE failed to return to the present active set. pmfailnonblindinterfreqhofailrevertpsinteractivegreater pmattnonblindinterfreqhopsinteractivegreater64 Drop due to IFHO failure for PS streaming and others: Outgoing IFHO failure when UE failed to return to the present active set. pmfailnonblindinterfreqhofailrevertstreamingother 100 pmattnonblindinterfreqhostreamingother INTER-RAT HANDOVER The significant difference between handover and Inter-RAT Cell Change or Cell Reselection is that for handover dedicated resources must first be allocated in the target cell and then the UE is ordered to go to the allocated resources. For Inter-RAT Cell Change or Cell Reselection the UE is ordered (Inter-RAT Cell Change), or it takes the initiative (Cell Reselection) to go to the target cell and after arrival to the target cell use common channels, to inform the system of the Inter-RAT Cell Change and request for dedicated resources, if needed. The WCDMA RAN also supports handover to/from GSM for coverage reasons. In later releases, it will be possible to perform this Inter Radio Access Technology (Inter-RAT) handover for capacity or priority reasons, as illustrated in Figure Ericsson 2006 LZT R1C

153 4 Service Retainability Handover from GSM to UMTS because of high load or system priority Handover from UMTS to GSM because of bad coverage UMTS GSM GSM Network Multi RAT terminal Figure 4-21 WCDMA Handover (Inter RAT Handover) The IRAT handover and cell reselection functionality enables the system to move the connection from the UMTS to the GSM system and vice versa. The most common scenario with the introduction of UMTS systems would be when moving out of the UMTS coverage and then transfer the call to GSM system before/without dropping the connection since GSM initially will have a larger coverage footprint. IRAT functionality also enables the operator in a basic way to steer traffic between the GSM and the UMTS systems. The default system behavior is that GSM HO is not supported for the higher interactive DL rates 384 and 128. These rates will normally be downswitched to 64 when the coverage deteriorates, and when the connection has been switched to 64 the GSM HO functionality will work normally. If an event 2d was triggered earlier, the GSM measurements will start as soon as the switch to 64 occurs. The UE can measure on a maximum of 32 GSM cells. There are reasons to be restrictive when defining GSM neighbors, and it is recommended to not define GSM neighbors if it is not needed. The time it takes for a UE to find a candidate GSM cell generally increases with longer neighbor cell lists, and keeping the list short should generally lead to less time in compressed mode and better retainability performance. If the WCDMA coverage falls quickly, the probability of quickly finding a suitable GSM candidate cell will increase if there are fewer GSM cells to measure on. In this section, the equations for Inter Radio Access Technology (GSM) Handover success rate per service are covered. LZT R1C 2006 Ericsson

154 IRAT Handover Speech Therefore, it is of importance to set the IRAT parameters for the GSM and the UMTS systems so that the resulting functionality meets the intended strategy of the operator for its 2G/3G subscribers and services. The following metric measures hard handover success rate between UtranCell and target GSM cell for speech calls. The formula is considering the GsmRelation. pmnosuccessoutirathospeech 100 pmnoattoutirathospeech IRAT Handover CS57 The following metric measures hard handover success rate between UtranCell and target GSM cell for CS streaming calls. The formula is considering the GsmRelation. pmnosuccessoutirathocs pmnoattoutirathocs57 IRAT Handover Multi-RAB The following metric measures hard handover success rate between UtranCell and target GSM cell for Multi-RAB calls. The formula is considering the GsmRelation. pmnosuccessoutirathomulti 100 pmnoattoutirathomulti IRAT Handover Packet Data The WCDMA to GSM cell change for PS interactive services normally experience quite long outage times before the session can be reestablished on the GSM side. There are no normal tuning activities that can be performed to shorten this time. The outage time can be divided into 2 parts. The first radio-outage part depends largely on the UE and consists of the time it takes for the UE to reselect to the GSM cell and then perform LA and RA updates. This typically takes 8-10 seconds. The second part is the Application outage that depends on the application, the protocol and on the TCP-IP procedures, before the application is running normally again. For some applications, like FTP download, this time could in the worst case be around 10 seconds Ericsson 2006 LZT R1C

155 4 Service Retainability The following metric measures cell change failure rate between UtranCell and target GSM cell for PS calls when the UE successfully returns to UtranCell. The formula is considering the GsmRelation. pmnooutiratccreturnoldch 100 pmnooutiratccatt MISSING NEIGHBOUR RELATIONS The amount of dropped call due to missing neighbor is depended on the value of releaseconnoffset parameter. If this parameter is set high, the number of drop due to missing neighbor will be low but the trade of is that the interference level will be increased due to overshooting. One of the reasons for dropped call that can be seen through statistics is drop due to missing neighbor relation. Normally a missing neighbor is reported to RNC as a detected cell. If the detected cells are not in RNC neighbor list for a concerned cell and the reported Ec/No value is greater than the serving cell plus the value of releaseconnoffset parameter, the call will be released (drop from end-user point of view) to reduce the interference level of this area. Shows fraction of speech drop due to HO action when a valid or non-valid cell cannot be added to active set. This includes also drop due to missing neighbor. 100 pmnosysrelspeechsoho pmnosystemrabreleasespeech ( + pmnonormalrabreleasespeech) Shows fraction of speech drop due to missing neighbor reason when a non-valid cell cannot be added to active set. 100 pmnosysrelspeechneighbr pmnosystemrabreleasespeech ( + pmnonormalrabreleasespeech) In order to find missing neighbor relation the GPEH recording function could be used. The event that is interesting for this case and provides relevant information is INTERNAL_SOHO_DS_MISSING_NEIGHBOUR. By activation of this event and collection of enough data (2-3 days), a number of potential missing cells will be identified. This list needs to be review to exclude overshooting cells that needs to erased. LZT R1C 2006 Ericsson

156 100 OTHER REASONS For cells with full neighbor list (32 entries) it is necessary to monitor the current handover statistics in order to know the usage of existing neighbor list. Note that Ericsson does not recommend to put in more than 20 entries in the neighbor list. New relations found through missing relation analysis can replace neighbor relations with low usage. In order to do the ranking of cell usage it is possible to use INTERNAL_SOFT_HANDOVER_EXECUTION event in GPEH for 2-3 days with efficient load to get enough data. It is also possible to use cell relation based counters such as pmrladdsuccessbestcellspeech and pmrladdattemptsbestcellspeech from performance statistic counters. Cell relation based counters should be activated for concerned cells and their neighbors to provide information regarding how often an existing neighbor relation is used. Drop due to other reasons, could be anything else such as UE problem, active set update failure (timer expiration), network malfunctioning, congestion on transport side during handover, RNC queues (Buffer_1A_1C or Buffer_1B) are full, etc.. This portion of dropped calls is calculated based on subtraction of known reasons for drop from the total dropped call. Dropped calls due to other reasons than uplink out of sync and missing neighbor can be calculated through using counters. In reality, there is no known reason behind this part of drop when looking at counters. Shows fraction of speech drop due to other reasons than HO action, UL out of sync and congestion. ( pmnosystemrab Re leasespeech pmnosys Re lspeechsoho pmnosys Re lspeechulsynch pmnooftermspeechcong) ( pmnonormalrab Re leasespeech + pmnosystemrab Re leasespeech) Ericsson 2006 LZT R1C

157 4 Service Retainability Transport Network The dropped calls due to transport network is not a radio problem, however it is important to find where that faults are so it could be solved. Shows percentage of rejected incoming/outgoing Aal2 connection establishment requests on transport network. 100 Where ( Y + X ) ( pmsuccinconns Re mote + pmsuccoutconns Re mote + Y + X ) X = pmunsuccoutconnslocal + pmunsuccoutconnsremote Y = pmunsuccinconnslocal + pmunsuccinconnsremote WNCS (WCDMA NEIGHBOURING CELL SUPPORT) WNCS is a tool included in the RNO product family. The purpose of WNCS is to evaluate the neighboring cell relations and to provide an easy and efficient way to keep the neighbor relations in the WCDMA Radio Network optimized. This means that support is provided to find missing neighboring cells that should to be defined as neighbors, and to find currently defined neighbor relations that can be removed. WNCS is mainly used for: Trouble shooting: Missing neighboring cell relations can be detected. Supervision: The neighboring cell relations can be evaluated continuously. Planning areas with new cells: WNCS can be used to evaluate new cell relations when new cells are added to the network. Only neighbor relations between WCDMA cells using the same frequency (ARFCN), that is the neighbor relations used for soft/softer handovers, can be optimized with WNCS. LZT R1C 2006 Ericsson

158 It is recommended to include maximum 300 cells belonging to 5 RNCs in one WNCS recording. The User Equipment (UE) continuously monitors the radio environment. Not only defined neighbor cells are measured, but also cells that are undefined neighbors can be detected with the background scanning process. The UE is configured to evaluate and send measurement reports to the system only when certain events occur, such as when the measurement result for a cell fulfills certain criteria. This concept is called event-triggered reporting. Events are collected by the General Performance Event Handling (GPEH) function in the RNC and sent on to Performance Management Support (PMS) in the OSS, where they are included in a Result Output Period (ROP) file. One file is created for each RNC and Result Output Period. WNCS schedules recordings of GPEH events via PMS, collects the files, and processes the events related to the measurements of surrounding WCDMA cells. It also collects and presents counters that measure the extent of defined WCDMA neighbor relations usage. The results are presented in various reports Ericsson 2006 LZT R1C

159 4 Service Retainability TEMS INVESTIGATION FINDINGS Below in the following sections there are several different problems found with TEMS Investigation in a WCDMA network. LOSS OF ASU COMPLETE OR MEASUREMENT REPORTS UE has sent active set update complete message to the UTRAN. However, the UTRAN does not reply the UE with measurement control to update the new monitored set cells list. The uplink RF performance is very bad. UTRAN cannot receive the measurement Figure 4-22 Loss of ASU complete. Possible Cause: DL/UL Imbalance LZT R1C 2006 Ericsson

160 The UE sends many measurement reports to request adding a cell; however, the UTRAN does not reply the measurement report by sending active set update message. The uplink RF performance is very bad. UTRAN cannot receive the measurement Figure 4-23 Loss of measurement reports. If the uplink RF performance is very bad, e.g., CPICH_RSCP is low and UE_Tx_PWR is high. Thus, it can be assumed the UTRAN cannot receive the active set update complete message. If the serving CPICH_Ec/No is still good, the problem then is the UL / DL coverage imbalance. The problem can be solved by reducing the pilot power and by adding new site. If the serving CPICH_Ec/No is bad as well, it is poor coverage issue. The unique solution is to add new site. If the serving CPICH_Ec/No is good as well as the CPICH_Ec it can be the timetotrigger parameter settings. The unique solution is to change the timers to a different value Ericsson 2006 LZT R1C

161 4 Service Retainability INTER-RNC HANDOVER FAILURE In TEMS Investigation, inter-rnc handovers can be monitored as well as all types of handovers. However, in this case below, the UE sends many measurement reports to request adding a cell, which is in the other RNC, into active set. The UTRAN does not reply the measurement report. After connection drop, the UE can be connected to that cell. If the UE then sends measurement reports to request adding the previous cell, which is located in the first RNC. The UTRAN does not reply the UE. Figure 4-24 RC Handover failure. Possible Cause: Network configuration LZT R1C 2006 Ericsson

162 UE RELATED PROBLEM The RF conditions for the new cell, SC75 is good however the AS SC56 is getting worse. Due to the many pilots in the area they might affect the inter-rnc handover. In this case the handover failed in both directions due to the fact that the UTRAN did not reply to the UE requests. Regarding the inter-rnc handover, the Iur link between the RNC can also be wrongly configured or that the neighbors are not correctly defined in the different RNC. The UE sends a MR to remove the best SC from the AS. After this SC is removed, the other ones in the AS become very bad in terms of Ec/No and the UE has no time to add it back to the AS. The UE sends a MR to remove SC204,which is the best server SC. Figure 4-25 Inconsistent Lists. Possible Cause: DL/UL Imbalance Ericsson 2006 LZT R1C

163 4 Service Retainability In the AS, there are two SC s, RF conditions become very good for one of them and bad for the other, and UE Tx power is low. It is assumed that the good radio link is out of synchronization because the DL BLER is increasing while the RF conditions become better for one SC. Finally the call drops because high DL BLER. DL BLER increases while SC183 is gets better and SC308 is gets worse Figure 4-26 TEMS Investigation DL BLER Increases and the call is dropped. LZT R1C 2006 Ericsson

164 Intentionally Blank Ericsson 2006 LZT R1C

165 5 Service Integrity 5 Service Integrity Objectives Upon completion of this chapter, the student will be able to: Understand how to analyze and interpret the collected data in order to improve the BLER and throughput Analyze RAN performance and propose adjustments related to integrity LZT R1C 2006 Ericsson

166 Intentionally Blank Ericsson 2006 LZT R1C

167 5 Service Integrity INTEGRITY INTEGRITY WORKFLOW WORST CELLS FORMULAS WCDMA POWER CONTROL CRC CYCLIC-REDUNDANCY CHECK DL INNER LOOP UL INNER LOOP UL OUTER LOOP POWER CONTROL ON HSDPA CHANNELS BLER PARAMETERS PACKET THROUGHPUT HSDPA HW AND SW PREPARATIONS OPTIMIZING THE HSDPA TEMS INVESTIGATION FINDINGS HIGH DL BLER - NO RAB SETUP HIGH DL BLER DROPPED CALL LZT R1C 2006 Ericsson

168 Intentionally Blank Ericsson 2006 LZT R1C

169 5 Service Integrity INTEGRITY INTEGRITY WORKFLOW This module is done after the retainability module. Integrity is defined as the ability of user to retain its requested service at a certain quality once connected for the desired duration. The performance is measured by the BLER (BLock Error Rate) and by throughput. The purpose of Integrity check-up is to track down excessive BLER problem and analyze them in a WCDMA network. Below the Figure 3-2 is showing the Integrity workflow. At performance monitoring the worst cells regarding integrity is sorted out. At performance analysis the worst cells are analyzed to find the BLER problems and then the throughput of the cells are checked Through the Recommendation and Implementation phase parameters will be looked upon in order to make a change of the networks performance. Through the Verification phase, the collected statistics before anything is implemented is compared to the statistics collected after the implementation is done. This is to ensure that there has been an improvement. Performance Measurements Performance Analysis Recommendation & Implementation Verification of changes BLER counters and Down Switching counters BLER, power, SIR parameters Throughput Test the settings Check statistics If not OK, roll back pmfaultytransportblocksbcul pmtransportblocksbcul pmnoofswdownngcong PmNoOfSwDownNgAdm PmDl Traffic volume counters Figure 5-1 A The Integrity workflow LZT R1C 2006 Ericsson

170 At the end of the workflow, when the verification of the implemented changes is done. Below is the proposed scenario how Integrity service can be performed. 1. Through performance statistics data (RNC counters) identify RAB s that are not performing in line with targets (blerqualitytargetul). That means - uplink BLER derived from counters is higher than UL BLER Target value set by parameter. Usually this should not be the case. 2. Review radio parameter settings (points below). Perform a consistency check of the parameter settings and verify settings against Ericsson default/recommended values. NOTE: WCDMA technology in Power Control has mechanisms to keep BLER lower then blerqualitytargetul/dl (UeRc parameter). If this is not the case it can be that parameters related to RAB s and Power Control have wrong values. Most of the mature networks have these values checked several times in the Consistency check procedures. - Check RAB parameters on the RNC level (blerqualitytargetul and blerqualitytargetdl) (also in Retainability module) - Check the values of the Power Mapping parameters, Maximum Downlink Transmitted Code Power. - Check UL Outer Power loop parameters (SIRMax, ul SIR Step). (also in Retainability module) 3. Check if it makes sense to investigate different blerqualitytarget settings (for example, what is happening changing target from 1 to 2% for voice) The performance can be verified after modifying BLER target by - Integrity counters, on RNC level after combining per RAB - Counters related to congestion, admission control and number of simultaneous users - RBS counters related to carrier, code power and RSSI Ericsson 2006 LZT R1C

171 5 Service Integrity Generally, there will be 2 types of finding from these analyses. Either the findings are related to Cell/RBS/RNC parameter settings, or they are related to hardware configuration such as antenna tilt or antenna height etc. WORST CELLS Observability of Integrity is very limited, only UL BLER per RAB on RNC level can be monitored. The system is designed to fight against BLER deviations from the set BLER targets. The ability to influence Integrity is somehow very small. There are two counters on cell level before combining pmfaultytransportblocksbcul and pmtransportblocksbcul. These counters are measured also during the time when cell is not the best in the active set. These counters do also contain BLER information for all RAB s. The method for finding worst performing cells is based on top to down analysis. Initially worst performing cells can be identified based on the Uplink Block Error rate before combining. pmfaultytransportblocksbcul 100 pmtransportblocksbcul FORMULAS Below is described formula that is based on counters after macro diversity combining in uplink. The Formula below shows Block Error rate after uplink combining at RNC level. That means blocks in RNC coming from different legs in SHO are compared, each radio connection. pmfaultytransportblocksacul[uerc] 100 pmtransportblocksacul[uerc] UeRc stands for different RAB s (UeRc=2, Speech; UeRc=3, Video Call; UeRc=4, Packet Common Channel; UeRc=5, PS 64/64; UeRc=6, PS64/128, UeRc=7, PS 64/384; UeRc=10 multirab Speech+PS 0 or PS 64/64). LZT R1C 2006 Ericsson

172 WCDMA POWER CONTROL Power Control is essential for the smooth operation of a WCDMA system, because all users share the same radio frequency band through the use of different codes. There are three types of power control in WCDMA as illustrated in Figure 3-8. BLER:Block Error Rate SIR: Signal to Interference Ratio TPC: Transmit Power Control Uplink SIR target Uplink outer loop Downlink outer loop BLER-Measured Inner loop SIR-Target modified Downlink TPC Uplink TPC Downlink SIR target Open loop Starting power BLER-Measured Uplink SIR-Target SIR-Target modified Uplink SIR error RNC Figure 5-2 WCDMA Power Control Open Loop Power Control is performed in the uplink and downlink to calculate a minimum starting power for setting up a connection. In doing so the interference and power required is minimized. Inner loop Power Control minimizes the power and interference of ongoing connections by maintaining a minimum Signal to Interference Ratio (SIR). The Outer Loop Power Control algorithm is used to maintain the required Block Error Rate (BLER) for a service by modifying the SIR target of Inner Loop Power Control Ericsson 2006 LZT R1C

173 5 Service Integrity CRC CYCLIC-REDUNDANCY CHECK In the WCDMA Transmitter, the voice channel is passed through a vocoder, which produces a digital representation of the input analogue signal. After error protection this is fed into a data multiplexer where it is multiplexed with synchronization bits and control/signaling data and user data channels. This combined signal is passed to the transmit gating device. Finally, filtering and RF modulation is performed and the signal is passed to an antenna system. The Error detection and error protection of the data channels are performed using Cyclic Redundancy Check (CRC) coding, Forward Error Correction (FEC) and interleaving. In all radio systems the air interface will add noise to the signal, which will produce a distortion in the received signal. This noise will result in bit errors, that are what left the transmitter as logic 1 could be interpreted as a logic 0 if the level of noise lowers the amplitude below the threshold for logic 0. The same could be the case for a transmitted logic 0 being interpreted as logic 1. Cyclic Redundancy Check (CRC) is used to detect if there are any uncorrected errors left after error correction. Original Data 244 bits CRC Generator Original Data Transmitte r Checksum 12 bits RF Transmission Path Receiver Received Data Received Checksum If Checksums do not match, there is an error CRC Generator Re-Generated Checksum Figure 5-3 CRC Generator Blocks of data are passed through a CRC generator Figure 5-3, which will perform a mathematical division on the data producing a remainder or checksum. This is added to the block of data and transmitted. LZT R1C 2006 Ericsson

174 DL INNER LOOP The same division is performed on the data block in the receiver. If a different checksum is produced the receiver will know that there is an error in the block of data (alternatively there is an error in the received checksum). This knowledge is used to calculate Block Error Ratio (BLER) used in the outer loop power control. The longer the checksum, the greater is the accuracy of the process. In the example the checksum is twelve bits long. Twelve bits of binary information represents 4096 (2 12 ) different combinations. It could be imagined that various combinations of errors on the data and the checksum would produce the same checksum. The longer the checksum the less likely it is for this to happen. During a period of soft handover with downlink Inner Loop Power Control, starting the radio link at the correct power level coordinates the power of the radio links. Each RBS in the active set listen to the same sequence of TPC commands from the UE. Received TPC commands, however, may be affected by different errors, due to the different radio propagation conditions experienced by each of the soft handover links. Consequently, the transmitted power at different RBSs will start to drift, eventually leading to uncoordinated links. Power Balancing prevents this power drift problem by using a modified type of power control during soft handover. The UE maintains the QoS by sending Transmit Power Control (TPC) commands in every slot (i.e., 1500 times per second), requesting a power adjustment. The RNC calculates a reference power based on the transmitted code power measured in each radio link, and periodically sends it to the RBSs. The RLs belonging to an out-of-sync RLS are excluded from the calculation of reference power. If all RLSs are out of sync, the last available reference power is used. The RLs belonging to RBSs that do not support transmitted code power measurements are also excluded from the calculation of reference power. Each RBS involved in soft handover makes synchronized adjustments of the downlink power of the radio links according to the received reference powers. These adjustments are superimposed on the power changes due to downlink Inner Loop Power Control, and performed regardless of RLS synchronization status Ericsson 2006 LZT R1C

175 5 Service Integrity UL INNER LOOP As soon as the RBS starts transmitting the downlink DPCCH, it begins to regulate the uplink power of the radio link by sending TPC commands to the UE in each slot. The UE responds by slowly increasing power until uplink synchronization is reached. Immediately, the RBS starts estimating the SIR on the DPCCH. The TPC commands are derived according to the following scheme: If estimated SIR >= target SIR, the RBS sends a down command. If estimated SIR < target SIR, the RBS sends an up command. Figure 5-4 Uplink Inner Loop Power Control The UE responds to the command by changing the DPCCH power by 1 db in the direction indicated by the command. The ratio between DPCCH and DPDCH power is determined by gain factors. In case of soft handover, if TPC commands from all RBSs in the active set are up commands, UE increases the DPCCH power by 1 db. Otherwise, if at least one TPC command is a down command, it decreases the DPCCH power by 1 db. LZT R1C 2006 Ericsson

176 UL OUTER LOOP There are two alternative algorithms for uplink Outer Loop Power Control implemented. The parameter ulouterloopregulator determines whether to use the Constant Step Regulator algorithm (ulouterloopregulator=constant STEP) or the Jump Regulator algorithm (ulouterloopregulator=jump). The interaction between uplink Inner Loop Power Control and uplink Outer Loop Power Control is shown in Figure 5-5. Figure 5-5 Uplink Outer Loop Power Control The two configurable parameters sirmax and sirmin set the limits of the uplink SIR target, expressed in db Ericsson 2006 LZT R1C

177 5 Service Integrity Constant Step regulator The start point of SIR target regulation is determined by the Initial Uplink SIR Target (ulinitsirtargetlow or ulinitsirtargethigh) depending on the Spreading Factor of DPDCH. The Initial Uplink SIR Target is a configurable parameter defined according to the minimum Spreading Factor (SF) of the uplink Dedicated Physical Data Channel (DPDCH): ulinitsirtargetsrb for stand-alone SRB, ulinitsirtargetlow for RABs having minimum DPDCH SF equal to or higher than 32 and ulinitsirtargethigh for RABs having minimum DPDCH SF equal to 16 or 8. ulinitsirtargetextrahigh for RABs having minimum DPDCH SF equal to or lower than 4, i.e. dedicated (SRB) to dedicated (384/HS-DSCH) RAB establishment. Note ulinitsirtargetextrahigh is not used for uplink initial power setting but used for uplink outer loop power control To avoid windup effects on the uplink SIR target, the anti-windup mechanism prevents changes of the uplink SIR target in one direction if the uplink Inner Loop Power Control cannot make the uplink SIR reach the target in the same direction. E.g., if the uplink SIR is lower than the target by 5 db as the UE transmits at maximum power, no further increases of the uplink SIR target are allowed until the Inner Loop Power Control is back on track. Whenever the Cyclic Redundancy Check (CRC) indicates that the reception of a transport block is erroneous, the uplink SIR target is increased by configurable increment ulsirstep, expressed in db. Whenever NBR_OF_CRC_OK consecutive transport blocks are correctly received, the uplink SIR target is decreased by an equal step. The number of consecutive correct transport blocks needed to trigger a decrease of the uplink SIR target depends on the BLER target. The SIR target value in the Constant Step Regulator algorithm is controlled as shown LZT R1C 2006 Ericsson

178 Figure 5-6 SIR Target Behaviour According to the Constant Step Regulator algorithm Jump regulator The Jump Regulator increases the uplink SIR target by a configurable increment ulsirstep, expressed in db, whenever a transport block is erroneously received. When a block is correctly received, the uplink SIR target is decreased by a fraction of ulsirstep. This fraction, denoted UP_DOWN_STEP_RATIO, depends on the BLER target. If several transport blocks are received in one Transmission Time Interval (TTI), the change in the uplink SIR target will be based on the accumulated change individually caused by each of the transport blocks. To reduce the variations of the uplink SIR target, the change of uplink SIR target is always scaled by the number of transport blocks received in the corresponding TTI, as described by the following general equation: SIR t arg et: new = SIR t arg et + ulsirstep X Y + ( Z UP _ DOWN _ STEP _ RATIO) Z Where: ulsirstep Z X Y is the configurable parameter that defines the size of SIR target increment. is the total number of received transport blocks. is the number of transport blocks that have a CRC=OK. is the number of transport blocks that have a CRC=NG Ericsson 2006 LZT R1C

179 5 Service Integrity SIR target behaviour according to the Jump Regulator algorithm is shown in the figure below. Figure 5-7 SIR Target Behaviour According to the Jump Regulator algorithm POWER CONTROL ON HSDPA CHANNELS The principles and functionality of the power control for the HSDPA associated dedicated channels are the same as for the DPCH power control in previous releases. However, there is a new uplink dedicated control channel, HS-DPCCH, which is used for feedback information to the hybrid ARQ processes and for channel quality information The power of the HS-DPCCH is given as an offset relative to the DPCCH. The offset has different values depending on if the UE is in soft handover or not. Updates of the parameters for CQI and ACK/NACK transmissions can be done by Physical channel reconfiguration. The update can be triggered in two different ways: Triggered by RNC when the number of Radio Link Sets are changed Triggered by a request from RBS In a first establishment, the radio bearer setup procedure, the parameters related to CQI are signaled in "Measurement Feedback info" which is a part of the "downlink HS-PDCCH information" message and the parameters related to ACK/NACK are included in the Uplink DPCH power control info fields. CQI, ACK, NACK are the power offset factors related to power control. A closed-looplike update of the CQI/ACK/NACK Repetition Factors can further improve the reception quality on the HS-DPCCH. LZT R1C 2006 Ericsson

180 BLER PARAMETERS The parameters deltaack1, deltaack2, deltanack1, deltanack2, deltacqi1, deltacqi2, initialcqirepetitionfactor, initialacknackrepetitionfactor, and cqifeedbackcycle are all configurable and set per cell. The parameter setting in use is decided by the HS-DSCH serving cell The RBS can initiate updates of the CQI Repetition Factor, CQI Feedback Cycle and ACK/NACK Repetition Factors using the Radio Link Parameter update procedure. The parameter updates are initiated by the CQI reception performance. If the CQI report is regarded as non-reliable this is logged as a CQI error event in the RBS. Note that if the CQI Repetition Factor is set to a value higher than one (1) only the softcombined result of the CQI report is counted. blerqualitytargetul - This parameter decides the quality target of the different RABs in uplink. blerqualitytargetdl - This parameter decides the quality target of the different RABs in downlink. The blerqualitytargetul/dl is calculated according to: ( ) blerqualit ytargetdl/ Ul = 10Log10 BLER quality target for example when BLER quality target is 1% (0.01) blerqualitytargetdl/ Ul = 10Log10 0,01 ( ) = 20 The purpose of configurable BLER targets is to enable the operator to trade quality of the connections versus resource usage. Note: These parameters can be set per TrCh for every radio connection. Recommended values for these parameters can be found below. Default values for parameters blerqualitytarget UL/DL set on TrCH. RAB Type TrCH Default Value SRB SRB -20 ( 1% BLER) Speech 12.2 Speech SRB -20 (1% BLER) -20 (1% BLER) Conversational CS data 64 CS64 SRB -25 (0.3% BLER) -20 (1% BLER) CS Streaming 57.6 CS (1% BLER) Ericsson 2006 LZT R1C

181 5 Service Integrity PS Interactive 64/64 PS Interactive 64/128 PS Interactive 64/384 Speech+ PS Interactive 64/64 Speech+ PS Interactive 0/0 PS Streaming 16/64 +PS Int 8/8 Conversational CS data 64 + PS Int 8/8 PS Interactive 64/HS PS Interactive 384/HS PACKET THROUGHPUT SRB PS64 SRB PS128 SRB PS384 SRB Speech PS64 SRB Speech PS64 SRB PS Streaming PS8/8 SRB CS64 PS8/8 SRB Int 64 (UL) SRB (UL) SRB (DL) Int 384 (UL) SRB (UL) SRB (DL) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -13 (5% BLER) -13 (5% BLER) -20 (1% BLER) -25 (0,3% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -20 (1% BLER) -30 (0,1% BLER) -20 (1% BLER) -20 (1% BLER) -30 (0,1% BLER) Throughput is defined as the perceived user data rate from the application layer. This means that the throughput will never reach the peak rate, since the TCP and IP overhead, and retransmissions, have to be taken into account. The throughput can be expressed per session, per bearer or per cell. It is important when dimensioning to know if these overheads have been taken into account in the requirement. Session throughput and T Hold are illustrated in Figure 5-8 below. LZT R1C 2006 Ericsson

182 Figure 5-8 Packet Call showing Session throughput and T Hold Throughput is associated with the speed and time the data is transferred in the system on the radio interface. However a closer look for the accessibility and the channel switching statistics should be done when examining the throughput statistics for the packet data sessions. Distribution chart of PS Application Downlink Throughput Range 7% 56% 37% App throughput < 64 kps 128 kps <= App throughput < 384 kbps 64 kps <= App throughput < 128 kbps Figure 5-9 PS Application Downlink throughput from TEMS Investigation Ericsson 2006 LZT R1C

183 5 Service Integrity In TEMS Investigation the Best Server throughput is measured and reported in a table that shows the application throughput and RLC/transport channel (low-level) throughput per cell. Please note that the low-level throughput is measured differently for different handsets. The Application (end-to-end) throughput is also measured and reported in different tables and charts. PS Binned Application Throughput Statistics Min Average Max (kbps) (kbps) (kbps) Average Application DL 1,0 65,7 367,0 Average Application UL 1,0 7,0 39,0 Median Application DL Throughput for spreading factor = 32 1,0 38,6 122,0 Median Application DL Throughput for spreading factor = 16 1,0 49,7 169,0 Median Application DL Throughput for spreading factor = 8 4,0 92,5 367,0 Table 9 PS Binned Application-level Throughput Statistics Channel Switching Congestion control is used to resolve overload in both the uplink and the downlink. It uses Power and RSSI (Received Signal Strength Indicator) measurements. In case of overload, congestion control reduces bit rates of delay tolerant existing connections or as a second option, removes existing connections. When the Cell load rises due to the increased power requirement of for e.g. the UE that is moving away from the RBS. When this load reaches a defined limit the RBS must reduce it by switching non-guaranteed users to lower rate common channels. Channel Switching applies only to packet traffic on the interactive RAB, which has little or no quality of service attributes that apply. It belongs to the Interactive and Background Quality of Service classes, which have no guaranteed bit rates and no packet delay requirements. When sufficient resources are available, the interactive RAB receives high bit rates but when the system is heavily loaded and not many resources are available, the bit rates offered may be low. In a heavily loaded situation, it may not be given any bandwidth at all, since there are no guarantees on resource allocation for the RAB. Channel Switching switches only between transport channels. The logical channels are not affected. When large amounts of data are being sent or received, the DCH transport channel with various rates is available on both the uplink and the downlink. In addition, the HS-DSCH is available on the downlink and E-DCH is available on the uplink, both depending on UE and cell capability. LZT R1C 2006 Ericsson

184 For small amounts of data, the common transport channels RACH and FACH are used. In this case, for downlink, a maximum of 32 kbps is shared between all users in a cell. For no data activity, the interactive RAB is switched to URA state, where no transport channels are allocated and thus no data transmission is possible. Channel switching function works both on a Single RAB and on a Multi RAB combination. The Channel Switching function optimizes the resource usage by dynamically allocating different transport channels to the Interactive RAB of a UE. It consists of two parts: evaluation and execution. The evaluation part is responsible for monitoring the resource and coverage needs of a UE through measurement reports received from the UE, the RBS, and the RNC. A request to switch up or down in rates is made to the execution part when a need is detected. The execution part is responsible for (1) allocating the needed resources according to UE and cell capability and (2) executing the Radio Bearer Reconfiguration procedure for making the switch The Channel Switching evaluation is based on two criteria: user activity and coverage condition. User activity is measured in terms of either channel throughput or RLC buffer load and coverage in terms of downlink code power. The Channel Switching Algorithms can be triggered either by the UE or the RNC, depending on the behavior of the uplink and downlink, respectively. All of the Channel Switching evaluation algorithms have event triggered measurements, meaning that measurement reports are sent only when necessary. This means that the actual measurements are processed before reporting. The Channel Switching Algorithms use RLC buffer load, throughput, and transmitted code power as input to the algorithms. Not all Channel Switching algorithms are active in every state. An algorithm corresponding to a certain state is started once the state is entered successfully and stopped when a new state has been entered successfully. The switching is initiated by either the UE or the WCDMA RAN and is triggered by the Channel Switching Common to Dedicated Evaluation Algorithm based on measurements made by the WCDMA RAN or the UE. The Channel Switching algorithm group consists of the following sub-algorithms: Ericsson 2006 LZT R1C

185 5 Service Integrity Common to Dedicated Evaluation Dedicated to Common Evaluation Common to URA Evaluation (in P5) URA to Idle Evaluation (in P5) Coverage Triggered Downswitch Evaluation CELL_DCH to CELL_DCH Upswitch Evaluation Throughput based CELL_DCH to CELL_DCH Downswitch Evaluation (in P5) Multi RAB Downswitch Evaluation Multi RAB Upswitch Evaluation There are two states in connected mode: Dedicated state (Cell_DCH) and common state (Cell_FACH). These are associated with the transport channel on which the user data is sent. Channel Switching is activated in connected mode and handles switches between the different states or to idle mode. The switches between dedicated and common states are handled by WCDMA RAN without the involvement of the Core Network. The possible state transitions are shown in the figure below. Figure WCDMA Channel Switching LZT R1C 2006 Ericsson

186 Common to Dedicated UpSwitch An UE on a common channel can be switched down to idle mode if it shows no activity during a certain time interval. In this way, resources are made free and common transport channel (FACH/RACH) signaling over the Iur interface is avoided. It also decreases the power consumption of the UE, since the UE does not have to monitor the FACH for long periods of time. This switching is initiated by the WCDMA RAN and is triggered by the Channel Switching Common to Idle Evaluation Algorithm based on measurements made by the WCDMA RAN. The timer is used to release UEs that has been inactive too long. The Dedicated Channel (DCH) is well suited for high bit rate traffic, since it is reserved for one user and provides closed loop power control. High user bit rates create a lot of interference and power control is essential to keep the interference on an acceptable level. It is also important to keep the common transport channels free from everything but control information and small portions of user data, in order to keep system function execution times sufficiently low. The use of a common transport channel would negatively affect the throughput of other users. RLC Buffer load: The buffer load is defined as the minimum of the Radio Link Control (RLC) transmission window and the sum of bytes in the SDU buffers and retransmission buffers of some of the RLC instances (each interactive RAB connection consists of five RLC instances). When the RLC buffer load in the uplink exceeds the threshold value set by the parameter ulrlcbufupswitch, a measurement report is sent from the UE. An upswitch request is issued upon reception of the measurement report. A request is also issued when the RLC buffer load (in the RNC) in the downlink exceeds the threshold value set by the parameter dlrlcbufupswitch. Channel Switching execution thereafter performs the upswitch when permission is given from Admission Control. Only one radio link is set up, since it is the responsibility of Soft and Softer Handover to add radio links after switching is complete Ericsson 2006 LZT R1C

187 5 Service Integrity Dedicated to Common DownSwitch When setting dlrlcbufupswitch it is important to consider how much of the TCP signalling should be done on common and how much signalling should be done on DCH. For example, when a UE is used for web browsing, uplink traffic is started by a short DNS message. If ulrlcbufupswitch is set to a value smaller than the size of the DNS look-up message, an upswitch to DCH will be issued by the very first signaling from the UE which decreases the response time. On the other hand, a low setting of this parameter could make signaling from other applications trigger an upswitch when the UE is used as a modem for a laptop computer. Throughput: Uplink throughput is defined as the number of bits received to the RLC layer from the MAC layer. Downlink throughput is defined as the number of bits transmitted from the RLC layer to the MAC layer. The RLC instances to be considered for the buffer load and throughput measure depends on the UE state and the algorithm using the measurement. When the throughput on both the uplink and downlink is below the threshold value set by the parameter downswitchthreshold, the timer downswitchtimer starts (when on DCH/DCH) or the timer hsdschinactivitytimer starts (when on DCH/HS or EUL/HS). If the throughput increases above a second threshold set by the parameter downswitchtimerthreshold before the timer expires, the timer is stopped and no switch is issued. See Figure 5-11 Figure The dedicated to common channel switching evaluation If the downswitchtimer parameter is set to 0, the Dedicated to Common Evaluation algorithm is turned off, meaning that no down switches from dedicated to common will occur, irrespective of how long throughput has been below the threshold. LZT R1C 2006 Ericsson

188 Optimization of the down switch from dedicated to common channels is a direct trade-off between resource utilization and user throughput. The goal is to achieve a parameter setting that correctly estimates when transmission for a user has ended in order to release assigned resources as fast as possible. The behavior of this algorithm is determined by the setting of the downswitchthreshold and downswitchtimer parameters. The downswitchthreshold parameter determine how the radio access network should behave in the end of a TCP transmission. In general, when, e.g., a FTP download is over, throughput rapidly decreases to 0 kbps and then does not increase again until a new TCP transmission is started. Therefore, the default setting of this parameter is 0 kbps. However, the setting of this parameter is strongly dependent on the characteristics of the TCP traffic. If, for example, a UE is used as a modem connected to a laptop it can very well be the case that applications on the laptop creates a low rate background traffic. The combined TCP traffic caused by e.g. a FTP download and the background traffic could make it necessary to set a higher value of downswitchthreshold. This is to avoid that a TCP transmission - that after transmitting with a throughput close to 384 kbps during the FTP download goes down to the e.g. 4 kbps created by the background traffic - holds the resources associated to the 384 rate unnecessarily long. The downswitchtimer defines the time a user will stay on DCH with low throughput before being switched down to FACH. If this timer is set long, the probability that a user is switched down to FACH during short periods of inactivity decreases. This improves the user throughput, but also increases resource utilization and thereby decreases system capacity. It is therefore not recommended that this timer is used for generally improving user throughput. There are however traffic cases that can be improved by a slightly increased timer setting. For example, FTP transmissions can be split into several TCP transmissions. If the UE (or the laptop when the mobiles used as modem) uses this for FTP transmissions the user perception of the FTP transmission can be improved by a small increase of this timer. It should however be remembered that this then is done on the cost of system capacity Ericsson 2006 LZT R1C

189 5 Service Integrity URA Evaluation (P5) Coverage Triggered Downswitch URA Evaluation: The Common to URA Evaluation releases UEs with no activity in order to free resources. It also decreases the power consumption of the UE, since the UE does not have to monitor the FACH for long periods of time. The algorithm is activated at the entry of the CELL_FACH state. Uplink and downlink activity is monitored and the algorithm requests a switch to URA_PCH state if no uplink or downlink activity has been detected (i.e. no data has been transmitted) during inactivitytimer seconds. The request is issued to the Channel Switching execution function, which handles the further processing of the transition to URA_PCH state. The URA to Idle Evaluation releases UEs with no activity in order to free resources. The algorithm is activated at the entry of the URA_PCH state. The algorithm requests a switch to Idle mode if a UE has been allocated to URA_PCH state for InactivityTimerPch minutes. The request is issued to the Signaling Connection Handling function, which handles the further processing of the transition to Idle mode. Signaling Connection Handling issues an Iu release request to the Core Network, which in turn decides whether the connection should be released. Transmitted Code Power: Transmitted code power is defined as the downlink power of the pilot bits of the DPCCH field. The Coverage Triggered Down switch Evaluation algorithm monitors the code power utilization on the downlink. If the code power increases so that a switch to a lower rate dedicated channel on the downlink is required due to coverage reasons, a down switch request is sent to the Channel Switching Execution function. The goal is to minimize dropping due to bad link quality. When downlink transmitted code power increases too close to its maximum, there is a risk that the link quality cannot be maintained. In this situation, a user should be switched down to a lower rate to decrease the needed downlink transmitted code power. The function will control that no user is using a rate in an area where there is risk for no coverage of that particular rate. It is therefore important that the mapping for maximum downlink power is tuned so that desired coverage is achieved LZT R1C 2006 Ericsson

190 The algorithm monitors the downlink transmitted code power of all legs in the active set and the code power is then filtered by each RBS in the active set. A down switch request is issued when all handover legs use a power above the power alarm threshold. The power alarm threshold is defined by the parameter downswitchpwrmargin. If the transmitted downlink code power falls below the power alarm threshold while the timer coveragetimer runs, the request will be cancelled and no downswitch is executed. The actual coverage of each rate is given by the maximum downlink power per radio link. This maximum downlink power per radio link is determined through a per-cell definable mapping based on the maximum rate of the radio link. By adjusting the mapping, coverage can be increased or decreased. When adjusting the mapping, some restrictions apply. For the coverage testing before upswitch, the downlink maximum transmitted code power is the maximum code power of the current rate. Consequently, the mapping should not be defined so that the resulting downlink maximum transmitted code power of a lower rate is higher that the downlink maximum transmitted code power of a higher rate. If this is done, the coverage tester functionality could fail and it could happen that the link quality cannot be maintained after an upswitch have been granted. The average amount of transmitted code power is not only dependent on the used transmission rate and attenuation to the UE, but also on the blerqualitytarget parameters. By setting these parameters, average link quality can be traded for decreased resource consumption (i.e. transmitted code power). It is however then also important to notice that with decreased average link quality, user throughput will be decreased. From user throughput point of view it is therefore proposed that the blerqualitytarget is kept to a low vale (e.g. 1%). This evaluation algorithm is started at the entry of the single RAB states CELL_DCH 64/384 and 64/128 and Multi RAB states speech + 64/384, speech + 64/128 and 64/ / Ericsson 2006 LZT R1C

191 5 Service Integrity Channel Rate Switching The Dedicated to Dedicated Upswitch Evaluation algorithm determines whether a switch to a higher rate channel should be made. The same algorithm applies both for Single RAB and for Multi RAB. The algorithm monitors the uplink and the downlink throughput separately. A channel switch request to a higher uplink rate Radio Bearer (uplink triggered) or to a higher downlink rate Radio Bearer (downlink triggered) is issued if all of the following conditions are fulfilled: The downlink throughput increases above the threshold specified by bandwidthmargin or the uplink throughput increases above the threshold specified by bandwidthmarginul. For a trigger on the downlink, the transmitted code power consumption on the current rate is below the power upswitch threshold for all legs in the active set. The maximum bitrate capability for QoS profiling does not indicate that the current rate is the maximum bitrate for the user. After a throughput based downswitch, the downlink throughput has fallen below the threshold specified by dlthroughputallowupswitchthreshold or the uplink throughput has fallen below the threshold specified by ulthroughputallowupswitchthreshold. The upswitch timer is specified by the parameter upswitchtimer for a downlink trigger and upswitchtimerul for an uplink trigger. The power upswitch threshold is defined from the power alarm threshold (described below) through the parameter upswitchpwrmargin and the estimated power increase. The estimated power increase is based on the relative rate difference between the current and a higher rate. If the bandwidthmargin parameter is set to 0 or the bandwidthmarginul is set to 0, the Dedicated to Dedicated Upswitch evaluation is turned off for downlink or uplink respectively. If the dlthroughputallowupswitchthreshold parameter is set to 0 or the ulthroughputallowupswitchthreshold is set to 0, this condition is not used for downlink or uplink respectively. LZT R1C 2006 Ericsson

192 The Dedicated to Dedicated Down switch Evaluation algorithm determines whether a switch to a lower rate channel should be made. The same algorithm applies both for Single RAB and for Multi RAB. The algorithm monitors the uplink and the downlink throughput separately. A channel switch request to the next lower uplink rate Radio Bearer (uplink triggered) or to the next lower downlink rate Radio Bearer (downlink triggered) is issued in the following situation: The downlink throughput decreases below the threshold specified by dldownswitchbandwidthmargin or the uplink throughput decreases below the threshold specified by uldownswitchbandwidthmargin. If the above conditions holds for the duration of a down switch timer, a down switch request is executed by the Channel Switching function. The downswitch timer is specified by the parameter dlthroughputdownswitchtimer for a downlink trigger and ulthroughputdownswitchtimer for an uplink trigger. If the dldownswitchbandwidthmargin parameter is set to 0 or the uldownswitchbandwidthmargin parameter is set to 0 the Dedicated to Dedicated Downswitch evaluation is turned off for downlink or uplink respectively. TEMS Investigation and Statistics In TEMS Investigation the events PS Channel Type Switch Complete, PS Channel Type Switch Failure, PS RAB Channel Rate Switch Complete and PS RAB Channel Rate Switch Failure indicates however the channel switching was successful or not. The Channel rate switch is done according to a spreading factor change. pmnoofswdownngcong The counter shows number of times packet data connection downswitches from a dedicated channel to a common channel initiated by congestion control. If the down switch is not allowed to common, then the counter shows number of packet data system release due to congestion. PmNoOfSwDownNgAdm The counter shows number of times packet data connection downswitches from DCH 64/384 to DCH 64/128 and DCH 64/128 to DCH 64/64 initiated by admission control due to lack of downlink power or code limit Ericsson 2006 LZT R1C

193 5 Service Integrity RAB Sate DCH 64/384 DCH 64/128 DCH 64/64 FACH Packet RAB establishment actual throughput Figure Channel Switching in TEMS Investigation To compare the measured throughput (by TEMS Investigation) to the average throughput at the cell and at the RNC level could be done by looking at the traffic counters in at RBS and RNC level. Average throughput per cell and RAB in the DL: Throughput = pmdltrafficvolume < RAB > pmsum < RAB > RabEstablish * ROPsec pmsamples < RAB > RabEstablish The RAB efficiency can also be checked RAB Efficiency Actual Bitrate per RAB = Nominal Bitrate per UeRc = x The results gives the percentage of bitrate used compared with the maximum allowed by the RAB. In particular the speech RAB can be considered as the activity factor of the RAB. However this formula can not be used for HSDPA traffic. The throughput for HSDPA is calculated differently from the other RAB due to the fact that there is a new protocol involved, the MAC-HS. However if looking at transmitted bits the average HS cell throughput can be obtained: pmsumtransmitted bits * 500 pmnoactivesubframes + pmnoinactiverequiredsubframes The Average HS Cell throughput: pmsumackedbits * 500 pmnoactivesubframes + pmnoinactiverequiredsubframes LZT R1C 2006 Ericsson

194 HSDPA The operators will implement WCDMA High-Speed Downlink Packet Access to gain more throughput per cell and higher bit rate per user. HSDPA is useful mainly in good radio channel conditions (e.g. high C/I, Low speed). On the other hand HSDPA will use whole remaining power all the time, which means lower C/I. The HSDPA concept is based on the following features: Shared channel transmission Higher-order modulation Short transmission time interval (TTI) Fast link adaptation Fast scheduling HW AND SW PREPARATIONS Fast hybrid automatic-repeat-request (ARQ). The new transport channel type, using multi-code transmission, is shared dynamically in time and code domain among multiple users. HS-DSCH is rate controlled, higher bit rates: Mbps. Encoding rate, number of channelization codes and modulation type adapted, are based on available power. The adaptation is on 2 ms transmission time interval (TTI), e.g. 500 times/sec. This means the round trip delay is reduced on the air interface and the Fast Link Adaptation, Fast Radio Channel-dependent Scheduling and Fast hybrid ARQ with soft combining are possible. There are no need for new sites or for extra spectrum/carrier at the first deployment of HSDPA due to the fact that there are few UE available. However the software for the RNC, RXI and RANOS has to be upgraded as well as the RBS. In the RBS there are also a need for HW upgrade to new Baseband boards (HS-TXB and HS-RAXB). New and more efficient transmission solutions are necessary in order to serve the much higher bit rates. A wide range of ATM transmission interfaces e.g. E1, E3 & STM-1 as well as aggregation on Hub RBS and RXI level has to be installed Transport network efficiency features provided through SW upgrade Ericsson 2006 LZT R1C

195 5 Service Integrity OPTIMIZING THE HSDPA HSDPA feature tuning Most of the existing WCDMA Networks are tuned/optimised to handle 60-70% of the downlink load during busy hours. Their current power parameter setting is for handling that load as well. Implementing HSDPA the network can most of the time be loaded 100%. A higher-order modulation, 16QAM in complement to QPSK is used for higher peak bit rates. 16QAM allows for twice the peak data rate compared to QPSK but it will be more sensitive to interference. With HSDPA higher system capacity is achieved, 2-3 times more. The 16QAM is an optional feature in the Node B that will be implemented in P5. Fast Link Adaptation, data rate adapted to radio conditions on 2 ms time basis, adjusts transmission parameters to match instantaneous radio channel conditions, i.e. path loss, shadowing, interference variations and fast multi-path fading. There is no power control as such at the channels but the adaptation is based upon the CQI, Channel Quality Indicator. In order to increase the throughput the more channelization codes can be dedicated to the HS traffic. However in P4 the codes will then not be available for R99 traffic. With Fast Hybrid ARQ will re-transmissions of erroneous packets processed in the RBS be faster and soft combining of multiple transmission attempts to improve performance is used in the UE. With Fast Radio Channel-dependent Scheduling is scheduling of users on 2 ms time basis. Scheduling implies which UE to transmit to at a given time instant based on radio channel quality and targeting fading peaks. In P4 there are only Round Robin and the Proportional Fair scheduling algorithm available. Power parameters HSDPA will take whatever power that is left in RBS after common channels and dedicated channels has taken their part The average power utilization in the network will increase with HSDPA LZT R1C 2006 Ericsson

196 Power Max cell power HSDPA power Admission control threshold DCH power CCH power Figure HSDPA will take whatever power that is left in RBS time Power of the Common Channels, e.g. CPICH and SCH should be increased and verified. This because with 100% cell load the Pilot (CPICH) or other common channel should remain their quality in the cell. The power of non-hsdpa common channels is always set relatively to the primary common pilot channel power (primarycpichpower). These settings are chosen so that they ensure sufficient quality where the CPICH can be detected. Current deployed networks show that the default settings are robust and give good performance, both in terms of accessibility and retainability. Tuning common channel settings should be done primarily through modifying primarycpichpower, hence trading coverage for capacity In areas with poor coverage it is possible to increase the success of the random access procedure by maximizing the number of transmitted preambles. This is achieved by setting the parameter poweroffsetp0 to 1 db, preambleretransmax to 32, and maxpreamblecycle to 32. These settings ensure that the UE transmits the maximum number of preambles before aborting the attempt, thus ensuring maximum detection probability in the RBS. Tests have shown that the coverage improvement with this setting is in the order of 1-3 db Ericsson 2006 LZT R1C

197 5 Service Integrity Changing the poweroffsetp0 to 1 db lowers the power ramp step size from 3 db. This enables the UE to transmit more preambles at maximum UE power since the terminal aborts the ramping if the calculated UE power (P_PRACH) is 6 db above the maxtxpowerul. With 1 db power steps the UE will send 6 preambles at maximum power compared to 2 preambles with a poweroffsetp0 at 3 db. The potential drawback here is that the call set up time is slightly increased, since smaller power increase steps are taken. There is a trade off between call set up time, delay when in CELL_FACH state and coverage. Each preamble takes in the order of 5 ms. With an ideal initial power setting, the added delay in call set up will be 10 ms in the worst case. With a smaller power step size, the number of preambles must be increased to ensure that it is possible to reach the maximum power. For this reason maxpreambleretransmax is set to 32. Max power of the DCH (other RABs) should be increased and verified. This because with 100% cell load the DCH channel should remain their quality in the cell border, where they are using their max power. The uplink (UL) dedicated control channel HS- DPCCH provides fast feedback of HARQ acknowledgements and the Channel Quality Indicator (CQI) on the UL. Reliable reception of the HS-DPCCH is essential for good HSDPA performance. Power control of HS-DPCCH is given as an offset relative to DPCCH and there are different values depending on whether or not the UE is in soft handover. The reason for this is that the HS- DPCCH terminates in the RBS and is only received in the serving HS-DSCH cell. This implies that HS-DPCCH might have performance degradation when it is power controlled by multiple cells and the serving cell is not the best cell in the UL. Therefore higher power offset values are used when the UE is in soft handover and lower offsets otherwise. The drawback with the higher settings necessary for successful reception of HS-DPCCH is the higher resource cost (UL interference will increase). Therefore it is important to set these parameters correctly considering this trade-off. The updates of the power offset parameters are triggered by the RNC when the numbers of Radio Link Sets are changed. The power offset parameters are grouped into two namely deltacqi1, deltaack1, deltanack1 and deltacqi2, deltaack2, deltanack2. The first group is used when the number of Radio Link Sets (RLS) is equal to one (that is RLS=1) and the second when it is greater than one (that is RLS>1). LZT R1C 2006 Ericsson

198 Interference The power setting of HS-SCCH is fixed. The parameter hsscchmaxcodepwr determines the power level of HS-SCCH and is expressed as an offset relative to the PCPICH. The information element "HS-SCCH power offset" that can be carried over NBAP shall not be used. With HS-DSCH there is a new Radio Bearer defined for the A- DCH corresponding to a 3.4 kbps SRB in the downlink and a 64 kbps bearer in the uplink. Uplink initial power setting for the Interactive PS RAB 384/HS id cone with the parameter ulinitsirtargetextrahigh. After implementing HSDPA and having full load system the overall interference floor will increase and consequently the overall C/I will be lower. This because the network most probably as a best had been tuned to handle around 70% of the load but now the load can go up to 100%. Increasing a non-power-control-channel, e.g. pilot, means more power into the neighboring cells and hence higher interference in them as well. This high interference will cause higher power consumption per user and therefore lower cell capacity. The only way then to have lower interference is to retune the network. To have cells with as less coverage islands and as less overlapping (outside SHO areas) as possible. Then the power is located in areas where it is used and minimized the power in areas when it disturbs as interference. This means need of retuning. High sites generate interference outside the planned coverage area Tilting antenna is an efficient way of achieving confined cells Ericsson 2006 LZT R1C

199 5 Service Integrity Handover parameters System Load Depending on the operators design and tuning the whole network needs to be retuned to get better C/I everywhere. This because the network most probably as a best has been tuned to handle around 70% of the load but now the load can go up to 100%. This should not be mixed with above where it is based on a user/rab (or common channels), when here covers the capacity in the cell. HSDPA will not use SHO but hard HO (no macro diversity). This means in the SHO areas (cell borders) the HSDPA, which is already sensitive to interference, will be more sensitive and therefore retuning may be needed to optimize the original SHO regions more. After implementing HSDPA high data speed PS radio bearers e.g. PS384 may not need same coverage requirement as before and need to be retuned. HS-DSCH is not power but rate controlled, higher bit rates: Mbps. Encoding rate, number of channelization codes and modulation type adapted, are based on available power. To have a higher bit rates more power is needed. The DL Load is here measured as the percentage of used DL Power compared to the available one (including Common and Dedicated Channels). Two Load Condition Scenarios can be defined: Low Load represents the Off-Peak Hours. It is generally assumed that the transmitted cell carrier power mostly includes the DL Common Channel Power. High Load represents the Peak Hours with high transmitted cell carrier power By considering the additional interference generated by HSDPA Traffic from each cell, at both the Ec/Io and DL RSSI. The traffic load is considered in terms of DL Cell Transmitted Carrier Power. DL Cell Transmitted Carrier Power is the total DL transmitted power by a cell and it includes both Common and Dedicated Channel Power. The data can be obtained from the RBS counter pmtransmittedcarrierpower. LZT R1C 2006 Ericsson

200 TEMS INVESTIGATION FINDINGS HIGH DL BLER - NO RAB SETUP Below in the following sections there are several different problems found with TEMS Investigation in a WCDMA network. In TEMS Investigation the High DL BLER problem can be found. The last downlink message which the UE gets its Call Proceeding. After this, the connection drops. Before the drop, the DL BLER rapidly increases. However, the CPICH_RSCP and CPICH_Ec/No are good. There are no other interference cells over the problematic location. Figure 5-14 Example of high DL BLER and no radio bearer setup One possible cause could be that the UTRAN failed to prepare the radio bearer and the UE time expired and then terminated the connection Ericsson 2006 LZT R1C

201 5 Service Integrity HIGH DL BLER DROPPED CALL Another possible cause could be that the UE was faulty and caused high DL BLER. Then the UE did not receive the RB Setup message from the UTRAN. Finally, the UE terminated the call setup. In TEMS Investigation the High DL BLER problem can be found. The connection is dropped after UE sends Radio Bearer Setup Complete message. Before the drop, the DL BLER rapidly increases. However, the CPICH_RSCP and CPICH_Ec/No are good. Typically, UE Tx power increase high but not all time. There are no other interference cells over the problematic location, but in some cases there were many handovers during call setup. There is no DL signaling after the Radio Bearer Setup Complete message The UE TX power is high Figure 5-15 There is no DL signalling after the Radio Bearer Setup Complete LZT R1C 2006 Ericsson

202 One possible cause could be that the UTRAN failed to synchronize the radio bearer in UL. Another possible cause could be that the UE failed to properly establish the radio bearer and caused high DL BLER Ericsson 2006 LZT R1C

203 6 UETR and GPEH 6 UETR and GPEH Objectives Upon completion of this chapter, the student will be able to: Understand which tools that are available for optimizing a network Understand how to setup and retrieve UE Traffic Recording (UETR) Understand how to analyze the UETR files using the TEMS Investigation RAN analysis Understand how to setup General Performance Event Handling (GPEH) and analyze the GPEH files LZT R1C 2006 Ericsson

204 Intentionally Blank Ericsson 2006 LZT R1C

205 6 UETR and GPEH UE TRAFFIC RECORDING (UETR) UETR RECORDABLE MESSAGES AND MEASUREMENTS ADD A UETR SUBSCRIPTION PROFILE RETRIVE THE UETR LOGFILES ANALYZE THE UETR LOGFILES GENERAL PERFORMANCE EVENT HANDLING (GPEH) INITIATION OF GPEH GPEH FILES COLLECTION AND STORAGE GPEH FILE STRUCTURE GPEH FILE ANALYSIS USING RED GPEH FILE ANALYSIS USING TEMS LZT R1C 2006 Ericsson

206 Intentionally Blank Ericsson 2006 LZT R1C

207 6 UETR and GPEH UE TRAFFIC RECORDING (UETR) UETR is a performance recording function in WCDMA RAN. It allows the operator to record the important events and behaviour on a selected UE or UEs traveling through a network. Only one UE may be selected per UETR recording, but one RNC gives the possibility of running up to 16 UETR simultaneously. If the UE crosses a RNC border, the UETR needs to be activated for both. The UEs to be traced are identified by the operator using their respective IMSI numbers. The operator can send out a test mobile (in particular after changes or extensions to the network) to record live traffic to investigate the performance of the network in a certain area. Event data in the RNC and measurement data from the RBS and UE, related to the air interface, are recorded. This function allows monitoring of specific information sent to and from the UEs. For example, the operator can check the data used to make handover decisions and from it identify parameters that need to be adjusted to achieve improved performance. The UETR administration is supported by OSS-RC, which provides capabilities for: 1. Starting a UETR recording for one RNC. 2. Viewing a UETR performance recording. 3. Modifying a UETR performance recording. 4. Activating and deactivating a UETR performance recording. 5. Listing all UETR performance recordings. 6. Starting UETR for multiple RNCs. 7. Viewing performance monitoring filters. The procedures related to the RANOS operation for UETR will be described below. LZT R1C 2006 Ericsson

208 The output file of UETR uses a proprietary Ericsson binary format with embedded protocol messages, internal events and measurements. The protocol messages are represented in the transfer syntax specified by the protocol standards as they appear on the RNC interfaces. The internal messages are specified by a proprietary ASN.1 definition and encoded in a BASIC-PER aligned variant. Note the file size for the UETR are limited in the RNC the parameter to control this is uetrfilesize. UETR RECORDABLE MESSAGES AND MEASUREMENTS Recordable messages UETR measurements The UETR function can be chosen to record one or more of the messages within one or more of the following protocol groups: 1. NBAP, between RNC and node B (Iub) 2. RANAP, between RNC and core network (Iu) 3. RNSAP, between RNCs (Iur) 4. RRC, between RNC and UE (Uu) The following measurements are reported through the RNC internal event: 1. Transport Channel BER, measured on DCH after radio link combination (ordered for all DCHs relating to the UE connections being recorded). Measurement period = 1xTTIs, reporting period = 5xTTIs. The measurement period is the frequency with which the measurement is received in band in the RNC from the RBS. The reporting period is the frequency with which sequences of values are reported to the RNC PM recording application internally in the RNC. 2. Transport Channel BLER: uplink DCH (ordered for all DCHs relating to the UE connections being recorded). Measurement period = 10s, reported period = 10s Ericsson 2006 LZT R1C

209 6 UETR and GPEH 3. RLC Buffer information, number of discarded DCCH SDUs, number of discarded DTCH SDUs, number of retransmitted DCCH PDUs and number of retransmitted DTCH SDUs (ordered for each downlink logical channel -per DCCH, per DTCH- associated with the UE being recorded). Report Period 10 s. This measurement is not reported from the UE, but is recorded in the RNC per UE. This is reported as an RNC internal event in the ROP file. The following two measurements are reported through NBAP Dedicated Measurement Report. For the user to receive any of these measurements in the recording ROP file, the measurements and the NBAP Dedicated Measurement Report message must be selected. 1. Uplink SIR per radio link set, measured on DPCCH after radio link combination in the RBS. All values recorded within a 960 ms period are averaged and reported every 960 ms (ordered for all RLs relating to the UE connections being recorded). 2. Transmitted Code Power, measured on the pilot bits of one channelization code for a DPCH. One average value is reported every 1000 ms (ordered for all DPCHs relating to the UE connections being recorded). The following two measurements are reported through RRC Measurement Report. For the user to receive any of these measurements in the recording ROP file, the measurements and the RRC Measurement Report message must be selected. 1. Transport channel BLER: downlink DCH is reported periodically every eight s (ordered for all DCHs relating to the UE connections being recorded). 2. UE transmitted power, reported periodically every second. LZT R1C 2006 Ericsson

210 ADD A UETR SUBSCRIPTION PROFILE The following procedure is used to add a UETR subscription profile: 1. Log into OSS-RC 2. Run the RANOS Network Explorer 3. Access the Data collection Subscription profiles window from the Data collection choice on the Performance menu of RANOS Explorer. The following window appears: Figure 6-1. Data Collection Subscription profiles 4. Click on the Profile in the main drop down menu; then click Add. A create subscription profile wizard appears. For example: Ericsson 2006 LZT R1C

211 6 UETR and GPEH Figure 6-2. Selecting the UETR profile 5. Select User equipment traffic recording profile (UETR); then click Next. The window Enter subscription profile name and comment pops up as shown below: Figure 6-3. Entering a profile name and comments 6. Enter a profile name and comment; then click Next. A window to select the RNC to be included, Step 3 of 6 pops up. For example: LZT R1C 2006 Ericsson

212 Figure 6-4. Selecting the involved RNC 7. Select the involved RNCs and then click Next. Select events for the UETR recording, Step 4 of 6 windows appears. For example: Figure 6-5. Selecting the protocols to be measured on Ericsson 2006 LZT R1C

213 6 UETR and GPEH 8. Select necessary events and then click Next. The Enter IMSI number for the UETR recording - window pops up: Figure 6-6. Step Entering the IMSI number In order to get the IMSI number for a subscriber in the network connect to the MSC and type the following command in the command handler. Mgtrp:msisdn = <mobile number> The mobile number should be the full number, including the country code MCC and the mobile network code MNC 9. Enter the IMSI number of the test UE and then click Next. The Select profile schedule wizard dialog -window appears. 10. Choose relative profile schedule and enter the duration, then click on the FINISH button. This is the last wizard step and the created profile is included in the Data collection Subscription profile dialog box. LZT R1C 2006 Ericsson

214 RETRIVE THE UETR LOGFILES On collection, the PMS renames the UETR files according to the convention below: A<Date>.<StartTime>-<EndTime>_<ShortNodeId>_< ShortScannerId>_<IMSI>_uetrfile.bin ANALYZE THE UETR LOGFILES Merging the files The files are stored in the folder: var/opt/ericsson/nms_umts_pms_seg/segment1/subnetwork=rnc 01/MeContext=RNC01 for 1 day. The UETR function traces the behavior of an individual phone by recording event data produced in the RNC, as well as measurement data from the RBS and from the phone itself. The phone-originated data is also a subset of what is found in the TEMS log file, although in the UETR file it is not tagged with any positioning information. The remainder of the UETR file data is referred to as "uplink data" within the TEMS Investigation framework. It should be noted that UETR files contain no idle mode data, only data from calls. The files can be recorded for voice calls only, not when running a data service. At present, TEMS Investigation is not capable of reading uplink data from other manufacturers' equipment. Uplink files can be replayed as-is in TEMS Investigation. They can however also be merged with the corresponding TEMS log files, producing output in the form of an augmented log file which can be replayed in the usual manner. The contents of the uplink file can thus be viewed concurrently with the downlink data recorded in the TEMS log file. A further advantage of merging the files is that geographic positioning can be obtained for the uplink data. The uplink data is presented as a separate class of information elements. The task of the merging algorithm is to time-align synchronize the information in the uplink files with that in the log files. A time offset can be expected between the clock that governs uplink file time-stamping (for UETR files, the RNC clock) and the clock in the PC on which the log files were recorded Ericsson 2006 LZT R1C

215 6 UETR and GPEH While an uplink file contains (usually) one complete call involving a specific phone (actually a specific IMSI, i.e. subscriber identity), a log file can comprise an arbitrary number of calls made by one or several phones. The typical situation, therefore, is that a log file corresponds to multiple uplink files, each covering a log file segment that concerns a single call. Figure 6-7. One TEMS Log file corresponds to several Uplink files. For each call in the log file, the merging algorithm extracts a number of key characteristics: start time, stop time, and information about handovers (time of occurrence and serving cells involved). Then, each uplink file is compared to each call in the log file with respect to these characteristics. The uplink files for which a reliable match has been found are finally incorporated into the log file, aligned as indicated by the calculated time offset. The output is a new log file (extension.log), augmented with the uplink information, which is represented as being reported by a fictitious phone "MS5". The merging algorithm may sometimes fail for certain uplink files; when this happens, additional information can be provided to align the uplink files manually. If the merging algorithm has enough to go on, that is, if all calls in the files can be readily distinguished from each other by means of the characteristics considered, the procedure is straightforward. However, if this is not the case for some uplink file, so that there is difficulty in finding an obvious best match for it, the procedure will fail for this file. Problems will thus arise with sets of similar calls, especially if they are short and lack distinctive features (namely, handover events). Fragments of calls, whether in uplink files or log files, are also more likely to be problematic, because either the start time or stop time and thus the call duration is unknown. LZT R1C 2006 Ericsson

216 Furthermore, the algorithm does not handle day transitions. Therefore, it cannot correctly process calls beginning before and ending after midnight, or deal with time offsets that are so large as to place part of the calls on a different day. In other respects, the size of the time offset does not affect the performance of the algorithm. The following procedure is used to load the UETR files into TEMS Investigation Data Collection. 1. Open the Export Log file window 2. Under Input files, enter the log file names, or click "Browse file" and select your files. (If several log files is chosen, the merge will be done separately for each log file.) 3. Under Directory, specify a directory for the output. Figure 6-8. Step 1 to 3 of 5 4. In the Format combo box, choose "Log file with uplink data". Click the Setup button. In the dialog that follows, it is setup how to perform the merge (Method tab) and what uplink files to include in it (Uplink files tab) Ericsson 2006 LZT R1C

217 6 UETR and GPEH Figure 6-9. Step 4 of 5 Unless the exact time offset is known beforehand, the merging should begin by running the algorithm described in the previous sections. (If the offset is known, the alignment can be carried out manually). Mobile to match in log file determines what log file data is considered when comparing it with the uplink files. If there are data from several phones in the log file, but uplink files for a single phone, it is appropriate to disregard the data from the other phones: this eliminates a source of uncertainty in the matching process and speeds it up. Place bounds on uplink file offset can be used if the size of the offset is fairly known and with this lower and upper bounds can be entered. This, too, increases the reliability and speed of the algorithm. 5. Start the merge The procedure will take some time. When it has completed, a message ("Export Result") stating success or failure for each uplink file will be received. If all uplink files have been successfully matched, the merge is done. If the algorithm has failed for some files, the Export Result window should not be closed. LZT R1C 2006 Ericsson

218 If no sufficiently reliable match is found for an uplink file, it is not included in the output log file. There are two possibilities: Either there is no match the data in the uplink file simply does not exist in the log file, or there is indeed a match to be found, but the algorithm has problems identifying it. In the latter case, the algorithm needs more precise information about the offset. Often several calls in the log file are good matches and there is a problem figuring out which is the correct one. Now, the offsets calculated for the successfully aligned uplink files (which should be nearly identical) should be similar to that of the remaining files as well. On the Method tab, check "Place bounds on uplink file offset" and enter upper and lower bounds based on the values observed in the Export Result window. The bounds should be tight enough to ensure that a call in the log file cannot be mistaken for an adjacent call If the procedure still fails for some files, they probably do not correspond to anything in the log file. It might be the case, however, that some files are corrupt (for instance, they might be truncated). Even so, you might want of course want to use them. There may also be a day transition problem. As a last resort, therefore, the alignment can be assigned by brute force, simply assuming an offset. On the Method tab, choose "Assume static offset time" and enter a value in the box. (The offsets obtained for the successfully aligned files should still be a good clue.). The remaining files will then be aligned unconditionally with the log file according to the chosen offset. There are limits to the accuracy that can be achieved in time aligning the uplink files. The accuracy is affected by the following factors The time offset for an uplink file is computed as the average of the offsets for all characteristic events detected in the call (call start, call end, handovers, etc.). Therefore, the longer the call, the more reliable the offset, and vice versa Measurement reports in UETR files are not tagged with time-ofday information, but merely with a counter that is reset after each handover. This may have the effect that the UETR measurement reports are imperfectly synchronized with the measurement reports from the phone Ericsson 2006 LZT R1C

219 6 UETR and GPEH Analyzing the files Older UETR file formats only contain timestamps with a resolution of 1 s, but in P4 the resolution is 1 ms. This places a general limit on alignment precision, since a lot of messages may be written to the log file within one second The merged files can then be analyzed in TEMS Investigation GENERAL PERFORMANCE EVENT HANDLING (GPEH) This chapter describes the General Performance Event Handling (GPEH) function and events for the Radio Network Controller (RNC) 3810 and RBS The GPEH function handles the management and collection of predefined events in the WCDMA RAN. These events are either Node-Internal or Inter-Node as listed below: RNC-Internal Events RBS-Internal Events RRC Inter-Node Events NBAP Inter-Node Events RANAP Inter-Node Events RNSAP Inter-Node Events The Node-internal events are events produced within the RNC or RBS, due to a specific occasion, for example in an algorithm. The Inter-node events are protocol messages sent or received from UE, RBS or RNC. The term Performance Management Subsystem (PMS) is used to describe the how the OSS-RC handles the performance management of the WCDMA RAN. For GPEH, the PMS function can be divided into three areas: Initiation of GPEH GPEH files collection and storage GPEH files notification LZT R1C 2006 Ericsson

220 INITIATION OF GPEH The PMS system can be used to initiate the GPEH in the RNC and RBS. This collection is carried out by an entity known as a Performance Monitoring (PMn), also sometimes called a "Scanner". The RNC provides 24 scanners at node startup, whereas the RBS provides only one. These pre-defined scanners are all empty. The Operations Support System Radio and Core (OSS-RC) is used to specify the contents and activate the scanners. Recording starts at the beginning of the next 15-minute Result Output Period (ROP) after activation from OSS-RC. The recorded data from all active scanners is collected in a common data file per Main Processor (MP). The cell filter specifies in which cells in the RNC events shall be recorded. If an event does not include any cell identifier, it will match the filter anyway and be reported. To select GPEH file settings: 1. Launch OSS-RC for a selected RNS 2. Select WCDMA RAN measurements from the dropdown selection, see figure below. Figure WCDMA RAN measurements OSS_RC workspace menu Ericsson 2006 LZT R1C

221 6 UETR and GPEH 3. Create a performance profile for each selected RNC. Select WCDMA RAN measurements from the dropdown selection, The following window appears: Figure Select the General performance profiles Figure Selecting the GPEH events LZT R1C 2006 Ericsson

222 4. Selecting the GPEH events are similar to the UETR configuration; however there are two filter parameters in GPEH to be selected, Ue_Fraction and Cell. If an event is not related to a specific UE, the event will match the Ue_Fraction filter anyway and be reported. The cell filter specifies in which cells in the RNC events shall be recorded. If an event does not include any cell identifier, it will match the filter anyway and be reported. 5. Start the recording For further information, see General Performance Event Handler CPI documentation, 23/1551-AXD /1. GPEH FILES COLLECTION AND STORAGE The events are collected in GPEH data files, also called GPEH ROP files. The events are written to file in the order they appear in the buffers and are not ordered chronologically. For each 15-minute ROP period, the following two types of file are generated: Main File The main file contains administrative information about the GPEH recording and links to sub files. Sub file A sub file contains recorded events for all active scanners. One main file generated on the O&M MP and one sub file per Module MP concludes each ROP. Each file has a unique name. Main file: <Type><Date>.<StartTime>-<EndTime>_gpehfile:2.lnk Subfile: <Type><Date>.<StartTime>-<EndTime>_GPEH.lnk Type start_date start_time end_time Always set to "A" - single Network Element and single recording/granularity period YYYYMMDD HHMM HHMM Example: Main File: A :00-18:15_gpehfile:2.lnk Subfile: A :00-18:15_GPEH.lnk Figure 6-13 GPEH File naming convention Ericsson 2006 LZT R1C

223 6 UETR and GPEH GPEH FILE STRUCTURE In the RNC events are recorded in the GPEH files until the end of the ROP or until the file has reached its maximum allowed size. The GPEH Main files are stored the same directory as the statistics and recording files, until the maximum allowed space in this directory has been reached, at which point the oldest files will be deleted. NOTE: If the OSS-RC cannot read GPEH file storage location attribute from the node it will assume the files are stored in the default location specified by the parameters listed below: RbsGpehDefaultFileLocation RncDefaultFileLocation The GPEH binary files are collected by PMS from the NEs using standard ftp/s-ftp services on TCP ports 20/22. Collection starts 5 minutes after each ROP end. This 5-minute delay allows the node to close the file with the data reported for the relevant ROP. Once the main files are collected from the node they are renamed by PMS and stored in a separate subdirectory for each RNC and RBS. Sub-folders are sorted per Radio Network Subsystem (RNS) and each RNS subdirectory is further divided into subdirectories per RNC and RBS. Subfolders names match names of the Subnetworks, RNSs and nodes defined by the configuration management application in OSS-RC. The Main File contains the following records: Header Administrative information about the file. Recording Scope of the recording. Protocol The name and version of the protocol from which messages can be recorded (RRC, NBAP, RANAP, RNSAP). Link A link from the main file to a GPEH sub file on another MP. Footer Administrative information about the time of normal termination of the ROP file. Error Contains the time and cause of an abnormal termination of a recording. The error record replaces the footer record if the file is terminated abnormally. LZT R1C 2006 Ericsson

224 Along with a footer or error, the sub file contains the numerous Body records, explained below: Body The body contains event records. The event record contains details about inter-node events and RNC-internal events. It is only the sub file that has a body record. A detailed explanation of the events can be found in the General Performance Event Handling RBS (61/1551-HRB /1 Uen) document in the Operation and Maintenance/Performance Management directory in the RBS library (CXP /2 R6A) and in the RNC library (CXP , from R6A). An example of GPEH RNC-Internal event id 386 is shown in Figure 6-14 below. EVENT Hour: 22 Minute: 45 Second: 00 Millisecond: 677 Event_ID: 386 Name: INTERNAL_RADIO_QUALITY_MEASUREMENTS_RNH C_ID_1: 4241 RNC_ID_1: 41 EVENT_TRIGGER: 9 MEASURED_ENTITY: 4 MEASURED_VALUE: 18 Figure 6-14 GPEH RNC-Internal Event Example The EVENT TRIGGER number relates to one of 52 triggers listed below: Event Parameter Trigger No. EVENT_VALUE_BELOW_NEG_UL_SIR_GUARD 0 EVENT_VALUE_ABOVE_POS_UL_SIR_GUARD 1 EVENT_VALUE_BETWEEN_POS_NEG_UL_SIR_GUARD 2 EVENT_VALUE_DL_POWER_INCREASE 3 EVENT_VALUE_DL_POWER_DECREASE 4 EVENT_VALUE_COMMON_MEASUREMENT_REPORT 5 EVENT_VALUE_LOAD_INCREASE 6 EVENT_VALUE_LOAD_DECREASE 7 EVENT_VALUE_EVENT_TRIGGERED_REPORT 8 EVENT_VALUE_PERIODIC_REPORT 9 EVENT_VALUE_REQUEST_FOR_DL_CODES_FOR_NORMAL_MODE 10 EVENT_VALUE_RELEASE_OF_DL_CODES_IN_NORMAL_MODE 11 EVENT_VALUE_ALLOC_FAILED_EXCESS_RATE_REQUEST 12 EVENT_VALUE_ALLOC_FAILED_NO_SUITABLE_CODE_FREE Ericsson 2006 LZT R1C

225 6 UETR and GPEH EVENT_VALUE_REQUEST_FOR_DL_CODES_NORM_TREE_COMP_MODE 14 EVENT_VALUE_REQUEST_FOR_DL_CODES_ALT_TREE_COMP_MODE 15 EVENT_VALUE_RELEASE_OF_DL_CODES_IN_COMP_MODE 16 EVENT_VALUE_EVENT_1A 17 EVENT_VALUE_EVENT_1B 18 EVENT_VALUE_EVENT_1C 19 EVENT_VALUE_EVENT_1D 20 EVENT_VALUE_EVENT_2D 21 EVENT_VALUE_EVENT_2F 22 EVENT_VALUE_ADD_CELL_PROPOSAL 23 EVENT_VALUE_REMOVE_CELL_PROPOSAL 24 EVENT_VALUE_REPLACE_CELL_PROPOSAL 25 EVENT_VALUE_UE_LEAVES_DCH_STATE 26 EVENT_VALUE_CELL_UPDATE_RECEIVED 27 EVENT_VALUE_CELL_UPDATE_CONFIRMED_SENT 28 EVENT_VALUE_RCS_CU_TIMER_EXPIRED 29 EVENT_VALUE_RL_SETUP_OR_ADDITION_RESPONSE_RECEIVED 30 EVENT_VALUE_RL_RESTORE_RECEIVED 31 EVENT_VALUE_RL_FAILURE_RECEIVED 32 EVENT_VALUE_RL_DELETION_RESPONSE_RECEIVED 33 EVENT_VALUE_RCS_WAIT_TIMER_EXPIRED 34 EVENT_VALUE_PROPOSED_HO_TO_GSM 35 EVENT_VALUE_PROPOSED_CC_TO_GSM 36 EVENT_VALUE_EVENT_3A 37 EVENT_VALUE_IU_RELEASE_COMMAND 38 EVENT_VALUE_RAB_ASSIGNMENT_REQUEST 39 EVENT_VALUE_REQ_FOR_NORMAL_UL_SCRAMBLING_CODE 40 EVENT_VALUE_REQ_FOR_REDUCED_UL_SCRAMBLING_CODE 41 EVENT_VALUE_OTHER_TRIGGER 42 EVENT_VALUE_EVENT_6A 43 EVENT_VALUE_EVENT_6B 44 EVENT_VALUE_START_IEF_MEASUREMENTS_PROP 45 EVENT_VALUE_STOP_IEF_MEASUREMENTS_PROP 46 EVENT_VALUE_START_GSM_MEASUREMENTS_PROP 47 EVENT_VALUE_STOP_GSM_MEASUREMENTS_PROP 48 EVENT_VALUE_EVENT_2B 49 EVENT_VALUE_PROPOSED_IFHO 50 EVENT_VALUE_COMPLETED_IFHO_ATTEMPT 51 The MESURED_ENTITY number relates to one of the five entities listed below: Measured Entity No. EVENT_VALUE_UL_SIR_ERROR 0 EVENT_VALUE_DL_TX_CODE_POWER 1 EVENT_VALUE_UL_INTERFERENCE 2 EVENT_VALUE_DL_TX_CARRIER_POWER 3 EVENT_VALUE_NON_HS_POWER 4 The MEASURED-VALUE is the estimated percentage Downlink Power in the cell. The RRC, NBAP, RANAP and RNSAP inter-node events are sometimes called protocol events since they contain the Layer 3 protocol messages as specified by 3rd Generation Partnership Project (3GPP). Each L3 protocol message is given an Event_id. LZT R1C 2006 Ericsson

226 An example of a RBS-Internal Event 257 (gpehrlssupstartedev) is illustrated in Figure 6-15 below. EVENT Hour: 20 Minute: 23 Second: 09 Millisecond: 467 Event_ID: 257 Name: gpehrlssupstartedev Number of cells: 1 RNC cell id 1: 4153 RNC cell id 2: 0 RNC cell id 3: 0 RNC cell id 4: 0 Figure 6-15 GPEH RBS-Internal Event Example In this example Radio Link Set supervision has started on Cell Ericsson 2006 LZT R1C

227 6 UETR and GPEH GPEH FILE ANALYSIS USING RED The Recording and Event Data (RED) subsystem also known as the Recording Events Interface (REI) provides the following main functions: 1. RED listens for notifications from PMS. 2. Once notified RED will extract the ROP file and store it in either the CTR, UETR or GPEH subdirectory of the parent directory below: /var/opt/ericsson/nms_umts_red_reg/downloaded. 3. The user can use the WCDMA Recording File Viewer to convert these binary ROP files to ASCII text files or tab delimited files. An example of these functions being performed for a UETR file collected from RNC01 is illustrated in Figure 6-16 below. g /var/opt/ericsson/nms_umts_red_reg/downloaded RED Notification from PMS UETR.bin WCDMA Recording File Viewer UETR.txt /var/opt/ericsson/nms_umts_pms_seg/segment1 RB/SubNetwork=RNC01 S /MeContext=RNC01 UETR.bin PMS Figure 6-16 WCDMA Recording File Viewer LZT R1C 2006 Ericsson

228 The Recording File Viewer window is launched from the Performance menu in the OSS Network Explorer Graphical User Interface (GUI). From the Performance drop down menu, choose WCDMA Recording file viewer as illustrated in Figure 6-17 below. Figure 6-17 Launching WCDMA Recording file viewer The Recording File Viewer main window is divided into two panes with a menu bar along the top of the window as illustrated in Figure 6-18 below. Menu Bar Search Criteria Search Results Ericsson 2006 LZT R1C

229 6 UETR and GPEH Figure 6-18 Recording file viewer graphical user interface The top pane is used to select the search criteria. The lower pane is used to display details of files relevant to the selection criteria specified. The information in some columns will vary depending on the type of recording that is being represented. The main Recording File Viewer window asks the user to input a number of fields to specify what criteria to use when outputting the recording results. The fields are: Type *: Select the Type of recording result file you wish to view: - CTR - UETR - GPEH You must at least select a Type in order to activate the search (This field is mandatory as indicated by the asterisk). The period you wish the recording result file to be viewed is specified with: From: start date/time interval for recording files To: end date/time interval for recording files Log entries can be filtered by date by selecting the earliest log entries with the From option and the latest log entries with the To option. The From and To dates are expressed as year, month and day. To change these click on the box. This will display the Calendar Dialog GUI. To change the year click on the arrows, to change the month click on the month drop down menu and select the month required. Finally to change the day click on the required day on the calendar. Once the required date has been selected click Apply. Select the desired time by clicking on it or highlight it by holding down the left button on the mouse and type in the desired time. NE: Specify the NE (Network Element) from which the recording file is to be retrieved. Depending on the Type of recording selected one of the following fields will be enabled: LZT R1C 2006 Ericsson

230 Performance monitoring ID (for CTR and UETR) or Node Type (for GPEH) Source: The Recording Source is also dependent on the recording type: - Cell/RDN for CTR - IMSI for UETR - Main Processor Number for GPEH Click Search to view a log of result files. If none of the above fields are filled in then Search will return all files relevant to the Type specified. Figure 6-19 below shows all the fields of the Recording File Viewer Search criteria. Specify Network Element Specify ID for UETR and CTR Specify Node Type for UETR - Cell/RDN for CTR -IMSI for UETR - Main Processor Number for GPEH Figure 6-19 Recording File Viewer Search Criteria The File menu contains Open, Save, Open Merge, Save Merge and Properties drop down options as illustrated in Figure 6-20 below Ericsson 2006 LZT R1C

231 6 UETR and GPEH or Open recording file in predefined editor Save (download) file to a predefined path Parse, convert, and merge group of files Parse, convert, merge, and save to default filename View properties of a job Figure 6-20 File drop down menu options Click Open to open the selected recording file in the predefined editor. This can also be achieved by clicking on the icon in the menu bar. Click Save to save (download) the selected recording file to predefined path. This can also be achieved by clicking on the icon in the menu bar. Click Open Merge to parse and convert into tab delimited format a group of recording files selected by the user. Merge these files together into a single file and download this to the editor set as default. Click Save Merge to parse and convert a group of recording files selected by the user into tab delimited format. Merge these files together into a single file and download this to the editor set as default and save to filename set as default. Note: Recommended Editor for Merged Files is a spreadsheet editor. LZT R1C 2006 Ericsson

232 GPEH FILE ANALYSIS USING TEMS TEMS Visualization quickly displays a large volume of data about calls made on an Ericsson WCDMA network. The enhanced capabilities in TEMS Visualization will identify quality problems and congestion by switching between WCDMA and GSMA modes. The effects of recent network changes and to get a better understanding of radio network behaviour. The problem spots, root causes will be identified and the trouble shooting can start. Following is a list of things that can be done with TEMS Visualization: Mode switch between WCDMA and GSM Load multiple Recording Output Periods (ROP) files sets into one database View and compare RF measurements, messages and events for calls including the flow of handovers for WCDMA networks See the WCDMA network infrastructure of cells on a map, including serving cells, neighbors, and the flow of a call among cells See the events, radio environment and graphical position of serving cells Identify abnormal events such as drops, blocks and handover failures Identify issues faced by subscribers by analyzing the data The operations are supported from system version OSS-RC2.2 and the UMTS Radio Access Network P3 by TEMS Visualization Ericsson 2006 LZT R1C

233 6 UETR and GPEH Setting up TEMS Visualization for analysis The workflow for the setup and the analysis can be visualized in the figure below. Figure 6-21 Workflow for analysis of the GPEH log files 1. During this first phase the different data files should be imported through the import wizard in order to create a database The cell files are showing cell infrastructure of the tested area and should be in the format of.cel or.xml. TEMS Visualization uses the GPEH log files that are created with a performance recording in the OSS and the log files should have a.bin or a.bin.gz filename extension. The folders where the GPEH files are stored will be asked for. The user can choose to filter some of the calls and/or call messages by the WCDMA Call filter. LZT R1C 2006 Ericsson

234 2. If the user has already created a database, the first step is skipped by just loading the database. 3. The maps are imported. They can be MapInfo tables (.tab), MapInfo workspace (.mws) or MapInfo geoset (.gst) Figure 6-22 TEMS Visualization User interface with all files loaded The TEMS Visualization analysis Once a log file has been processed and the data is in a database, all calls can be selected in order to be analyzed. The calls can be searched through criteria or calls analyzed for a specific cell. Figure 6-21 shows the workflow and as shown, there are three major paths to follow. Normally all the pilot pollution should be analyzed first, secondly the missing neighbors and last the call analysis part Ericsson 2006 LZT R1C