User Description, Radio Network Statistics USER DESCRIPTION 216/1553-HSC 103 12/16 Uen E Copyright © Copyright Ericsson AB 2010. All rights reserved. Disclaimer No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Contents Contents 1 Introduction 1 2 Capabilities 3 3 Measurement Tools for Radio Network Performance 5 3.1 General 5 3.2 Monitoring and Performance Tools 5 3.3 Implementation Tools 6 3.4 Troubleshooting Tools 7 4 STS 9 4.1 General 9 4.2 STS on APG 10 4.3 Statistical Analysis 11 4.4 Object Types Used for the Radio Network 11 4.5 Object Types Used for GPRS 24 4.6 Object Types for DTM 28 4.7 Object Types for GSM to UTRAN 29 4.8 Main Changes in Ericsson GSM System G10B/BSS G10B 29 5 GSM Radio Network Performance Monitoring 35 5.1 Introduction 35 5.2 Definitions and Explanations 35 5.3 General Traffic Information 36 5.4 Accessibility 38 5.5 Retainability 49 5.6 Speech Quality 58 5.7 Performance Measurement of Specific Radio Network Features 67 6 GPRS/EGPRS Radio Network Performance Monitoring 93 6.1 Introduction 93 6.2 Level One - IP Data Volume and GPRS Availability 96 6.3 Level One - IP Throughput 99 6.4 Level One - IP Latency 216/1553-HSC 103 12/16 Uen E | 2010-11-10 108 User Description, Radio Network Statistics 6.5 Level One - IP Transfer Interrupts Downlink (IP Buffer Discards) 113 Level One - IP Transfer Interrupts Uplink (MS to BSS Connection Issues) 116 6.7 GPRS user session counters for active users 121 6.8 Level One - Streaming Connection Negotiations 122 6.9 Level Two - Radio Link Quality 124 6.10 Level Two - GPRS Traffic Load 138 6.11 Level Two – GPRS Traffic load over Gb interface 148 6.12 Level Two - CS Traffic Load and PDCH Allocation 149 6.13 Level Two - Multislot Utilisation (PDCH Reservation) 153 6.14 Level Two - Mobility 159 6.15 Level Two - GSL Device Utilisation 160 6.16 Level Two - GPH RP Load 163 6.17 Additional Counters 165 7 Abis over IP and Abis Optimization Measurements and Counters 191 7.1 Frame Loss Ratio Formulas for Packet Abis 191 7.2 Delay measurements Formulas for Packet Abis 193 7.3 Additional Measurements for Abis Optimization and Abis over IP 196 7.4 STN counters used in Formulae 205 7.5 Summary of STS Counters for Abis over IP and Abis Optimization 206 Packet Abis Influence on Important BSS KPI and PI Measurements 221 8.1 IP Transfer interrupts 221 8.2 GPRS Availability 221 8.3 IP Latency GPRS 221 8.4 IP Throughput and Radio Link Bitrate measurements 222 8.5 IP User Data Volume (measured per hour) 223 8.6 CS Accessibility - Random access success rate 223 8.7 CS Accessibility - SDCCH Time Congestion 223 8.8 CS Accessibility - SDCCH Drop rate 223 8.9 CS Accessibility - TCH Assignment success rate 223 8.10 CS Retainability - TCH Drop rate 223 8.11 CS Retainability – Handover Success Rate and Lost Rate 224 6.6 8 216/1553-HSC 103 12/16 Uen E | 2010-11-10 User Description, Radio Network Statistics 8.12 CS Integrity SQI 224 8.13 CS Traffic Volume 224 9 A over IP Measurements and Counters 225 9.1 Counters for AGW RP CPU Load 225 9.2 Counters for AGW RP Traffic 226 9.3 RTP Configuration Changes Counters for A over IP 228 9.4 Capacity Locks for the A over IP Interface 229 10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters 231 10.1 How to Use This Dimensioning Methodology 232 10.2 Dimensioning Concepts 232 10.3 How to Dimension a Network 234 10.4 Simulation Results Presented in Graphs 235 10.5 Adjust Cells with Only B-PDCHs 239 10.6 Adjust Cells with B-PDCHs and G-PDCHs 246 10.7 Adjust Cells with B-PDCHs and E-PDCHs 254 10.8 Example of Dimensioning a Cell with Only E-PDCHs 261 11 GSM to UTRAN Performance Monitoring 265 11.1 Introduction 265 11.2 Monitoring GSM to UTRAN Handovers 265 12 IP Transport Statistics 267 12.1 Introduction 267 12.2 SNMP Infrastructure 267 12.3 IP Network Layers 268 12.4 SNMP-Based Counters 268 12.5 Formulae 274 13 Concepts 275 Glossary 279 Reference List 283 216/1553-HSC 103 12/16 Uen E | 2010-11-10 User Description, Radio Network Statistics 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Introduction 1 Introduction The purpose of this user description is to present different methods to measure the radio network performance and subscriber perceived quality. It contains a brief description of Statistics and Traffic Measurement Subsystem (STS) but focuses on the evaluation of the statistics for both general and feature specific performance in the radio part of Ericsson's GSM system. A brief description of some other performance measurement functions is also included. For more detailed information regarding counter units etc. see Reference [1]. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 1 User Description, Radio Network Statistics 2 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Capabilities 2 Capabilities Monitoring of statistical measures is a very important part of the Operation and Maintenance (O&M) of a radio network. The radio network statistic and recording functions can be used for: • Monitoring and optimization of the radio network performance • Evaluation and optimization of the radio network features • Dimensioning of the radio network • Trouble shooting 216/1553-HSC 103 12/16 Uen E | 2010-11-10 3 User Description, Radio Network Statistics 4 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Measurement Tools for Radio Network Performance 3 Measurement Tools for Radio Network Performance 3.1 General There are several different measurement tools for monitoring and improving the radio network performance. They could roughly be categorized in the three areas: monitoring and problem detection, help for implementation and support for troubleshooting. The monitoring tools are used for supervision and trouble detection in the whole network and the implementation tools support the operator at expansion or reallocation of resources, such as frequency planning or neighbor relation definitions. The troubleshooting tools could be used in specific areas or cells where the performance is deteriorated. Some of the most useful tools are presented in this chapter. 3.2 Monitoring and Performance Tools The monitoring tools are used for monitoring the network performance but also for continuous supervision acting as a support for expansions, reallocations, problem detection and general improvement activities. STN The Site Transport Node (STN) is used on the BTS site to terminate IP when using Abis over IP. In order to monitor the STN there are several counters available which can be collected via an open interface or OSS for post-processing. For detailed information, please see Reference [41]. STS Statistics and Traffic Measurement Subsystem (STS) is implemented in the BSC (and MSC). It gives statistics about events in different parts of the system such as cells and equipment. By continuously supervising the results from STS the operator can obtain a very good overview of the radio network performance which can help to detect problems early. For further information, see Reference [1]. MRR Measurement Result Recording (MRR) collects information from the measurement results sent by the BTSs to the BSC. Information such as RXLEV, RXQUAL etc. is included. The tool is for instance used for routine supervision or for checking specific cells. MRR is a part of the Radio Network Optimization (RNO) package in OSS, see Reference [28]. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 5 User Description, Radio Network Statistics TEMS Automatic Tems Automatic is a tool within the TEMS product portfolio, where several special mobile stations are placed in for instance taxis and buses. The set of mobiles are supervised centrally and the measurements are sent directly to this center. TEMS automatic provides the operator with information about subscriber perceived quality from many parts of the network. R-PMO 3.3 The real-time performance monitor provides real-time statistics in order to receive instant feedback of performance from sudden changes of the network, either by the network itself (e.g. hardware faults) or by operator initiated changes (i.e. parameter, feature or frequency changes). For operator initiated changes, faster tuning can be achieved. R-PMO also provides a high degree of detailed information, such as timestamps on events, and flexibility, such as user defined reports. See Reference [31]. Implementation Tools The tools for implementation are used during expansions, tuning or improvement activities and work as an assistant for the operator during the planning. The previously mentioned tools STS and MRR are also useful within this area. 6 NOX Neighboring Cell List Optimization Expert (NOX) is a tool meant as a support for the operator for optimization of the neighboring cell relations. This is done by collecting and handling data from measurement reports, handover statistics and general network configurations. The outcome are suggestions to remove superfluous or add new neighboring cell relations. The user can set whether the changes should be implemented automatically or require an approval by the user. SeeReference [29] . FOX Frequency Optimization Expert (FOX) measures for possible interferers in order to find suitable frequencies to define in cells. FOX supplies the operator with suggestions about frequencies at e.g. network/hardware expansions or frequency reallocations. See Reference [18] . SYROX Synchronized Radio Network Optimization Expert (SYROX) is a tool intended to support the operator with planning of parameters that control the frequency hopping for a group of Synchronized Cells in order to minimize the interference in the network. Apart from the fact that a group of mutually synchronized cells is 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Measurement Tools for Radio Network Performance required, SYROX also requires that the optional BSS features FAS (FOX recording mode), and Flexible MAIO Management are available. For more information see Reference [33]. NOX and FOX are included in the RNO package in OSS, and are based on the recording functions Frequency Allocation Support (FAS) and Neighboring Cell Support (NCS) respectively. 3.4 Troubleshooting Tools After detecting problems anywhere in the network, the troubleshooting tools can be used specifically in the area concerned. While the monitoring covers the whole area, these tools are more suitable for handling certain cells or relations. TEMS Investigation TEMS Investigation is a drive test tool within the TEMS product family. It consists of a TEMS mobile station, a PC with the TEMS Investigation software and a GPS receiver. The uplink and downlink information on the air-interface is monitored and recorded together with the positioning data from the GPS. TEMS Investigation, here referred to as TEMS, is a very powerful tool for field measurements during troubleshooting in specific areas of the network. MTR Mobile Traffic Recording (MTR) records the events and measurements on both the uplink and downlink connected to a certain subscription, which can be useful when a subscriber complains and the cause is to be investigated. MTR is also very useful together with TEMS. From TEMS geographical information can be retrieved but not from MTR. CER Channel Event Recording (CER) measures interference on the frequencies defined in the cell and is used when the performance of the channel allocation strategy is investigated. Idle Channel Measurement (ICM) or Differential Channel Allocation (DCA) is required for this recording, see Reference [25]and Reference [14]respectively. CTR Cell Traffic Recording (CTR) collects data about connections in specific cells. Certain events can be used as triggers and all communication on up- and downlink is recorded. CTR could be used if there are specific problems found in any cell, such as an abnormal number of Traffic Channel (TCH) drops. For detailed information regarding CTR, MTR and CER, see Reference [6]. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 7 User Description, Radio Network Statistics 8 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS 4 STS 4.1 General Different events occurring in an Ericsson GSM network are counted and collected by a subsystem called Statistics and Traffic Measurement Subsystem (STS). STS is available in one version, STS on APG. STS on APG is available on APG40/43 equipped BSCs. The central part in STS is the Measurement Database (MDB) where all measurements are collected from different blocks in the Central Processor (CP). The contents of the MDB are written to STS report files defined by the user. These STS files are then fetched from the BSC and processed by OSS or a user defined external tool. By combining and comparing different counters a general understanding of the radio network behavior can be obtained. The data base consists of several object types. The object types corresponds to different types of equipment, logical units or functions in the BSC. Every object type contains several objects (for example one per cell, compare with records) that have a number of counters (compare with record fields). Example: The object type CELEVENTD handles normal disconnections for each cell (object) and contains the counters, DISNORM (normal disconnection), DISBQA (disconnection at bad radio link quality), DISBSS (disconnection at low signal strength). DISETA (disconnection at excessive timing advance), DISFER (disconnection at high FER) and DISRET3G (disconnections with request to immediately connect to UTRAN network). For each cell the different events are recorded to the data base and accumulated. In the BSC these events can be handovers, call setups, dropped calls, allocation of different channels etc. There are also a number of status counters, reporting the status of equipment within the network such as the current number of occupied channels. During a call several counters are affected. The allocation of a Stand-alone Dedicated Control Channel (SDCCH) can be successful or fail due to congestion or the SDCCH could later drop due to low signal strength. Each event will result in different counters to be stepped. The reason for a handover decision can be normal or due to different conditions like bad quality urgency, HCS etc. All these events are recorded by the STS and can be used for further analysis. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 9 User Description, Radio Network Statistics 4.2 STS on APG STS on APG equipped BSCs is implemented in the APG. The frequency of the collection from the CP to the APG is determined by the Basic Recording Period (BRP) parameter, which can be set to 5 or 15 minutes. The collected data stored in the STS measurement data base consists of several object types. The object types can be reported to external systems in two different formats, ASN.1 files or load files. Note that the STFIOP format is not available from APG. The ASN.1 file format is based on the 3GPP IRP PM file format (see Reference [7]) and are used for transfer of statistics information to NWS/ENIQ in OSS. The load files are suitable for loading in to relational databases. It is possible to select formats for different types of data bases. The report interval can be set to a multiple of the BRP but may not exceed 24 hours. It may include data summarized over several BRPs. One report file may include counter data for several report intervals. The report file output interval may not exceed 24 hours and must be a multiple of the report interval. 4.2.1 Setup The setup of STS measurements contains several steps and can be done in either the STS application in OSS or in an interface application. SSH should be used to issue the commands to configure the APG. SFTP will be used for transfer of the report files. InReference [8] the setup and definition of STS on APG are discussed in detail, and the necessary steps can briefly be described as follows: 1 Consider which counters and time intervals that are needed for the analysis, e.g. drop counters for TCH during busy hour. 2 Start the data collection in STS, i.e. initiate the CP to collect data from the subsystems to the MDB in APG. 3 Define report identities and connect the object types to them, i.e. group the MDB information which is to be written to each file. 4 Define report intervals and time schedule, i.e. time, date and interval for the output to files. Please, see Reference [10], for further information about STS file definitions and counter calculations. 10 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS 4.3 Statistical Analysis The file output from STS should be processed to provide more information. In OSS the Network Statistics tool (NWS/ENIQ) can be used for the analysis, presentation and reporting of data. To obtain useful values and measures, counters from different object types usually have to be combined and compared. By using different formulas, figures for drop rate, handover success, congestion etc. can be obtained for each cell or BSC. As an example, the number of dropped TCH connections in a cell due to low Signal Strength (SS) can be compared to the total number of dropped TCH connections. The performance of different cells can also then be compared, see Section 5.5.2 on page 50. 4.4 Object Types Used for the Radio Network 4.4.1 Introduction The following object types concern the most important statistics measurements in the radio network part of an Ericsson GSM system. They include such matters as handovers, call setup, call drop and radio resource administration. 4.4.2 Structure of Object Types and Counters The naming of object types and counters follows some rules. For the object types the following is useful to know: Table 1 Mnemonic for Object Types CCH Control channel, in most cases in STS it means SDCCH, e.g. CELLCCH DR. N Neighboring cell. NI BSC-internal neighbor, e.g. NICELHO. NE BSC-external neighbor, e.g. NECELHO. NU UTRAN neighbor, e.g. NUCELLRELCNT. F/H Full rate/half rate, e.g. CELTCHDRF/CELTCHDH . V1/V2/V3 Speech Version 1/2/3, e.g. CELTCHFV1. O/U Overlaid/underlaid subcell, e.g. IDLEOTCHF. For the counters there are similar rules: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 11 User Description, Radio Network Statistics Table 2 Mnemonic for Counters C SDCCH, e.g. CDISSS. TF/TH or F/H Full rate/half rate TCH, e.g. TFNDROP/TH NDROP. TFV1/TFV2/TFV3 TCH full rate Speech Version 1/2/3, TCH half rate Speech Version 1/3, e.g. TFV1CALLS. THV1/THV3 4.4.3 UL/DL/BL or UP/DWN Uplink/downlink/both links, e.g. TFDISSULor CSMSUP . SUB Overlaid subcell. If omitted the counter designates underlaid subcell or both under- and overlaid subcell, e.g. TFSUDLOS or TFSUDLOSSUB. OL(UL) Handover from underlaid to overlaid subcell (underlaid to overlaid), e.g. HOSUCOL or HOSUCUL. SS/TA/QA Signal strength/ Timing advance/ Bad quality, e.g. DISBSS, DISETA, DISBQA HO Handover, e.g. CCHHOCNT 0 Channel group zero. A AMR G GPRS only capable MSs or B- and G-TBFs. E or EG EGPRS capable MSs or E-TBFs. Object Types - Summary The list below shows the BSC object types related to radio network statistics. A brief explanation and the counters in the object type are presented along with the object types. A more detailed description of the counters and the object types can be found in Reference [1] and Reference [4]. The object types described in these documents are sometimes sorted according to Speech Versions, half- or full-rate, neighbor type, subcell structures etc. When possible these object types are grouped and described together. Table 3 A Summary of Object Types Related to the Radio Network on BSC or TRC Level Object Type AGW 12 Short Description STS Counters Counters for AGW RP CPU Load. G2AGW0040LOAD, G2AGW4160L OAD, G2AGW6180LOAD, G2AGW 8190LOAD, G2AGW9100LOAD. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Object Type AGWTRAF AOIP AOIPCAP BSC BSCAMSG Short Description STS Counters Counters for AGW RP Traffic. FDELAY, FDELAYSCAN, REPLF, TRALACC, TRALSCAN, SENTSPF, RECSPF, KBSENT, KBREC, SENTSPFPCM, RECSPFPCM, SENTDFPCM, RECDFPCM, KBSENTPCM, KBRECPCM SENTMUXPKTMBS, SENTMUXPK TMBT, KBRECMUX, KBSENTMUX, SENTSPFMUX, RECSPFMUX, SENTSPFPCMMUX, RECSPF PCMMUX, SENTDFPCMMUX, RECDFPCMMUX. Counters for A over IP. CODECCHATT, CODECCHSUCC, TRMCHATT, TRMCHSUCC, CODE CSETCATT, CODECSETCSUCC. Counters for capacity lock for the A over IP interface AOIPATT, AOIPCONGCL, AOIPCONGOTH, AOIPPEAK, AOIPTCONG Paging and MS sessions BSCCUMMS, BSCMAXMS, GSM800CUMMS, GSM800MA XMS, GSM900CUMMS, GSM9 00MAXMS, GSM1800CUMMS, GSM1800MAXMS, TOTPAG, TOTCONGPAG Measurements for Messages on A Interface per BSC SPEECHCALL, FRSPV1, FRSPV2, FRSPV3, FRSPV5, HRSPV1, HRSPV3 BSCMSLOT Multislot connections TMASSALL, TMCASSALL, TMCNCMATT, TMCNCMSUCC, TMCNCBATT, TMCNCBSUCC, TMHOATT, TMHOSUCC, TMCHREQACC, TMCHRECACC, TMCHSCAN BSCRFSUP RF output power supervision ALRFPERFACC, ALNOTRAFACC, ALLOWDLQUALACC, ALNSCAN. BSCSCCCL Counters for Capacity Locks for SCC statistics TCONGAFR, TCONGAHR, TCONGAWB, TCONGEFR, TCONGHR, TRAFAFR, TRAFAHR, TRAFAWB, TRAFEFR, TRAFHR, TRAFSCAN. LOADREG Load regulation in the CP NREJPCH, NFTDEMC, NREJORG, NREJEMC, NREJPRIO, NREJNPRIO, NREJIEX 216/1553-HSC 103 12/16 Uen E | 2010-11-10 13 User Description, Radio Network Statistics Object Type PGW PGWLDIST TRH Table 4 ABISTG 14 STS Counters Counters for PGW RP CPU Load PBPGW0040LOAD, PBPGW4 160LOAD, PBPGW6180LOAD, PBPGW8190LOAD, PBPGW9 100LOAD, G2PGW0040LOAD, G2PGW4160LOAD, G2PGW6 180LOAD, G2PGW8190LOAD, G2PGW9100LOAD. Counters for PGW Load Distribution VHLSCGREL, SVHLSCGREL, HLSCGREL, SHLSCGREL, PGWHLRPP. Load on all GARP-2 RPs running the TRH application. G2TRH0040LOAD, G2TRH4160LO AD, G2TRH6180LOAD, G2TRH819 0LOAD, G2TRH9100LOAD. A Summary of Object Types Related to the Radio Network on MCPA Level, Transceiver Group Level or super channel level Object Type ABISIP Short Description Short Description STS Counters The counters are stored and presented per Transceiver Group (TG) and indicate the amount of IP traffic between BSC and BTS. IPSENTKBYTES, IPRECKBYTES, IPLOSTPACKUL, IPNUMSCAN, IPULRECPACK, IPDLSENTPACK, DL7075STNLOAD, DL7680S TNLOAD, DL8185STNLOAD, DL8690STNLOAD, DL9195S TNLOAD, DL9600STNLOAD, UL7075STNLOAD, UL7680S TNLOAD, UL8185STNLOAD, UL8690STNLOAD, UL9195STN LOAD, UL9600STNLOAD, DL10 0STNLOAD, UL100STNLOAD, IPOVLL1, IPOVLL2, PSDISCOVL, CSDISCOVL, IPOVLCSREG IPOVLPSREG. The counters are stored and presented per Transceiver Group (TG) and treat jitter buffer delay, jitter buffer drops and bundling group delay for ABIS over IP. DL0025JITBUFDEL, DL2650JI TBUFDEL, DL5175JITBUFDEL, DL7600JITBUFDEL, DL100JITBU FDEL, DLJITBUFAVDEL, UL0025 JITBUFDEL, UL2650JITBUFDEL, UL5175JITBUFDEL, UL7600JI TBUFDEL, UL100JITBUFDEL, ULJITBUFAVDEL, DLDROPJBUF, ULDROPJBUF, BUNDG0AVEDL, BUNDG1AVEDL, BUNDG2AVEDL, BUNDG3AVEDL, BUNDG4AVEDL. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Object Type MOMCTR NONRES64K RES64K SCABISDEL SUPERCH SUPERCH2 Table 5 Short Description STS Counters The counters are stored and presented per Multi Carrier Power Amplifier (MCPA) and show power utilization and service quality impact. BPWRO100, BPWR90100, BPWR8090, BPWR7080, BPWR6070, BPWR5060, BPWR0050, NUMTCHB, NUMT CHBRED, ACCTCHBREDDB, NUMPDCHB, NUMPDCHBRED, ACCPDCHBREDDB, NUMOB, NUMOBRED, ACCOBREDDB, NUMSDCCHB, NUMSDCCHBRED, ACCSDCCHBREDDB Status of the non-64K pool of Abis paths MIN16K, MAX16K, AVG16K. Status of the 64K pool of Abis paths MIN64K, MAX64K, AVG64K, FRAG64K. Delay measurements per super channel for packet Abis FJBUFDELDL, FJBUFDLSCAN, FJBUFDELUL, FJBUFULSCAN, FSCBUFDELDL, FSCBUFD LSCAN, FSCBUFDELUL, FSCBUFULSCAN. Super Channel quality counters SCGR, SC, KBSENT, KBREC, KBSCAN, KBMAXSENT, KBMAXREC, THRULPACK, THRDLPACK, LOSTULPACK, LOSTDLPACK, AVDELDLSCBUF, AVDELULSCBUF, TOTFRDLS CBUF, ULSCBUFTHR, TOTFR ULSCBUF, ULPSSCBUFTHR, DLCSSCBUFTHR, DLPSSC BUFTHR, TOTDLPSSCFRBUF, TOTULPSSCFRBUF, FCSLOSTUL, FPSLOSTUL, FCSLOSTDL, FPSLOSTDL. Superchannel load counters. DL7075SCLOAD, DL7680SCLOAD, DL8185SCLOAD, DL8690SCLOAD, DL9195SCLOAD, DL9600SCLOAD, UL7075SCLOAD, UL7680SCLOAD, UL8185SCLOAD, UL8690SCLOAD, UL9195SCLOAD, UL9600SCLOAD, SCOVLCSREG SCOVLPSREG. A Summary of Object Types Related to the Radio Network on Cell Level Object Type CELEVENTD Short Description Subscriber initiated disconnections 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Counters DISNORM, DISBQA, DISBSS, DISETA, DISFER, DISRET3G. 15 User Description, Radio Network Statistics Object Type Short Description STS Counters CELEVENTH Cell load sharing and handovers due to operation and maintenance intervention CLSTIME, TOTCLSTIME, HOATTLS, HOSUCLS, HOATTBL, HOSUCBL CELEVENTI Intra cell channel change BCDTCBCOM, BCDTCBSUC, BCLOSSCOM, BCLOSSSUC, HOSUCTCHOPT, HOINUQA, HOINDQA, HOINBQA, HOINSUC, HOINBOCH, HOATTHRPACK, HOSUCHRPACK CELEVENTS Handover between overlaid and underlaid subcells HOAATUL, HOSUCUL, HOAATOL, HOSUCOL, HOATTULMAXIHO, HOSUCULMAXIHO, HOATTOLMA XIHO, HOSUCOLMAXIHO CELEVENTSC Handover from overlaid to underlaid subcell, additional causes SCLDCOMUL, SCLDSUCUL, DTCBCOMUL, DTCBSUCUL, LOLCOMUL, LOLSUCUL, OLSCLDCOM, OLSCLDSUC, TAOLCOMUL, TAOLSUCUL CELLAFFER FER intervals in SQS data Collection TAF1ULFER, TAF2ULFER, for codec type AMR FR TAF3ULFER, TAF4ULFER, TAF5ULFER, TAF1ULSUBFER, TAF2ULSUBFER, TAF3ULSUBFE R, TAF4ULSUBFER, TAF5ULSUB FER, TAF1DLFER, TAF2DLFER, TAF3DLFER, TAF4DLFER, TAF5DLFER, TAF1DLSUBFER, TAF2DLSUBFER, TAF3DL SUBFER, TAF4DLSUBFER, TAF5DLSUBFER CELLAHFER FER intervals in SQS data Collection TAH1ULFER, TAH2ULFER, for codec type AMR HR TAH3ULFER, TAH4ULFER, TAH5ULFER, TAH1ULSUBFER, TAH2ULSUBFER, TAH3ULSUBFE R, TAH4ULSUBFER, TAH5ULSUB FER, TAH1DLFER, TAH2DLFER, TAH3DLFER, TAH4DLFER, TAH5DLFER, TAH1DLSUBFER, TAH2DLSUBFER, TAH3DL SUBFER, TAH4DLSUBFER, TAH5DLSUBFER 16 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Object Type Short Description STS Counters CELLAWFER Registration of FER intervals in SQS data Collection for Codec Type AMR-WB per cell. TAW1DLFER, TAW2DLFER, TAW3DLFER, TAW4DLFER, TAW5DLFER, TAW1DLSUBFER, TAW2DLSUBFER, TAW3DL SUBFER, TAW4DLSUBFER, TAW5DLSUBFER, TAW1ULFER, TAW2ULFER, TAW3ULFER, TAW4ULFER, TAW5ULFER, TAW1 ULSUBFER, TAW2ULSUBFER, TAW3ULSUBFER, TAW4ULSUBF ER, TAW5ULSUBFER, CELLBTSPS Counters for BTS Power Savings TRXOFF, TRXON, NUMTRXOFFP S, NUMTRXSCAN. CELLCCHDR Dropped connections for control channels CDISQA, CDISSS1...5, CDISTA, CDISQASUB, CDISSS, CDISSSSUB, CLUDISTA , CLUDISQA, CLUDISQASUB, CLUDISSS, CLUDISSSSUB CELLCCHHO Handovers on SDCCH CCHHOCNT, CCHHOSUC, CCHHOTOCH CELLCONF Adaptive configuration of logical channels CONFATTC, CONFATTT CELLDUALT Statistics on MSs capable of 900/1800 dual band. MSs with 900/1800 + extra band/bands will also be included TFDUALTRALACC, TFDUA LNDROP, TFDUALASSALL, TFDUALCASSALL CELLDYNPC Counters for dynamic BTS and MS power control BSINITDREGHO, CELLEFFER MSINITDREGHO FER intervals in SQS data Collection TEF1ULFER, TEF2ULFER, for codec type EFR TEF3ULFER, TEF4ULFER, TEF5ULFER, TEF1ULSUBFER, TEF2ULSUBFER, TEF3ULSUBFE R, TEF4ULSUBFER, TEF5ULSUB FER, TEF1DLFER, TEF2DLFER, TEF3DLFER, TEF4DLFER, TEF5DLFER, TEF1DLSUBFER, TEF2DLSUBFER, TEF3DL SUBFER, TEF4DLSUBFER, TEF5DLSUBFER 216/1553-HSC 103 12/16 Uen E | 2010-11-10 17 User Description, Radio Network Statistics Object Type Short Description STS Counters CELLFERF Frame erasure rate (FER) counters, full-rate TFV3FERCM1, TFV3FERCM2, TFV3FERCM3, TFV3FERCM4, TFV1FER, TFV2FER, TFV3TFCM1, TFV3TFCM2, TFV3TFCM3, TFV3TFCM4, TFV1FERTF, TFV2FERTF, TFV5FERCM1, TFV5FERCM2, TFV5FERCM3, TFV5TFCM1, TFV5TFCM2 and TFV5TFCM3 CELLFERH Frame erasure rate (FER) counters, half-rate THV3FERCM1, THV3FERCM2, THV3FERCM3, THV3FERCM4, THV1FER, THV3TFCM1, THV3TFCM2, THV3TFCM3, THV3TFCM4, THV1FERTF CELLFFER FER intervals in SQS data Collection TF1ULFER, TF2ULFER for codec type FR TF3ULFER, TF4ULFER TF5ULFER, TF1ULSUBFER, TF2ULSUBFER, TF3ULSUBFER, TF4ULSUBFER, TF5ULSUBFER, TF1DLFER TF2DLFER, TF3DLFER TF4DLFER, TF5DLFER, TF1DLSUBFER, TF2DLSUBFER, TF3DLSUBFER, TF4DLSUBFER, TF5DLSUBFER Counters on cell level for flexibly allocated Abis paths per cell. FLX8SUCC, FLX16ATT, FLX16SUCC, FLX64ATT, FLX64SUCC, FLXCS16ATT, FLXCS16SUCC. CELLMSQ Counters for the feature Prioritised MS Queuing NQPCCNT, RQHIGHCNT, NIQLOWCNT, RQT11CNT, NPCALLOCCNT, RQLOSSCNT, NQVGCS, NQPCUTRANCNT, RQHIUTRANCNT, NIQLOW UTRANCNT, RQTQHOCNT, RQLOSSUTRANCNT. CELLPAG Paging counters on cell level PAGPCHCONG, PAGETOOOLD CELLHCS Locating measurements for HCS TIMEHCSOUT, LOCEVAL, BRHILAYER CELLFLXAB 18 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Object Type Short Description STS Counters CELLHFER FER intervals in SQS data Collection TH1ULFER, TH2ULFER, for codec type HR TH3ULFER, TH4ULFER, TH5ULFER, TH1ULSUBFER, TH2ULSUBFER, TH3ULSUBFER, TH4ULSUBFER, TH5ULSUBFER, TH1DLFER, TH2DLFER, TH3DLFER, TH4DLFER, TH5DLFER, TH1DLSUBFER, TH2DLSUBFER, TH3DLSUBFER, TH4DLSUBFER, TH5DLSUBFER CELLHSCSD Measurement for High Speed Circuit Switched Data CELLMSCAP Counters for MSs with Miscellaneous SAICSCAN, SAICTRALACC, Capabilities per Cell THSAICTRALACC. CELLSQI Speech quality supervision measurements for TCH/Fs uplink. TSQIGOOD, TSQIACCPT, TSQIBAD, TSQIGOODSUB, TSQIACCPTSUB, TSQIBADSUB, TSQIGOODAF, TSQIGOODAH, TSQIGOODSUBAF, TSQIGOOD SUBAH, TSQIACCPTAF, TSQIA CCPTAH, TSQIACCPTSUBAF, TSQIACCPTSUBAH, TSQIBADAF, TSQIBADAH, TSQIBADSUBAF, TSQIBADSUBAH, TSQIGOODAW, TSQIGOODSUBAW, TSQIAC CPTAW, TSQIACCPTSUBAW, TSQIBADAW andTSQIBADSUBAW CELLSQIDL Speech quality supervision downlink TSQIGOODDL, TSQIGOO DSUBDL, TSQIACCPTDL, TSQIACCPTSUBDL, TSQIBADDL, TSQIBADSUBDL, TSQIGOO DAFDL, TSQIGOODAHDL, TSQIGOODSUBAFDL, TSQIGOODSUBAHDL, TSQIAC CPTAFDL, TSQIACCPTAHDL, TSQIACCPTSUBAFDL, TSQIACCPTSUBAHDL, TSQIBADAFDL, TSQIBADAHDL, TSQIBADSUBAFDL, TSQIBAD SUBAHDL, TSQIGOODAWDL, TSQIGOODSUBAWDL, TSQIACCPTAWDL, TSQIACC PTSUBAWDL, TSQIBADAWDL and TSQIBADSUBAWDL 216/1553-HSC 103 12/16 Uen E | 2010-11-10 TFHSCSDMAIN. TFHSCSDMAIN SUB, TFHSCSDNESEC, TFHSC SDNESECSUB, TFHSCSDESEC, TFHSCSDESECSUB 19 User Description, Radio Network Statistics Object Type Short Description STS Counters CLCCCH CCCH Availability CCCHAVAACC, CCCHSCAN. CLTCHDRAW Traffic measurements for dropped connections per cell level for TCH/F SPV5 TWDISTAA, TWSUDLOSA, TWSUDLOSSUBA, TWDISSDLA, TWDISSDLSUBA, TWDISSULA, TWDISSULSUBA, TWDISSBLA, TWDISSBLSUBA, TWDISQADLA, TWDISQADLSUBA, TWDIS QAULA, TWDISQAULSUBA, TWDISQABLA, TWDISQABLSUBA, TWDISFERULA, TWDISFERDLA, TWDISFERBLA, TWDISFERU LSUBA, TWDISFERDLSUBA, TWDISFERBLSUBA CELTCHF TCH/FR connections TFNCEDROP, TFNCEDROPSUB, TFNDROP, TFCASSALL, TFMSE STB, TFMSESTBSUB, TFCALLS, TFCALLSSUB, TFTCONGS, TFTCONSUB, TFTRALACC, TFNSCAN, TFTRALSUB, TFNDROPSUB, TFCASSALLSUB, TFCONGSAS, TFCONGSASSUB, TFCONGSHO, TFCONGSHOSUB, TFNRELCONG, TFNRELCO NGSUB, TFTHARDCONGS, TFTHARDCONGSSUB CELTCHH TCH/HR connections THTHARDCONGS, THTHA RDCONSUB, THNCEDROP, THNCEDROPSUB, THNDROP, THCASSALL, THMSESTB, THMSESTBSUB, THCALLS, THCALLSSUB, THTCONGS, THTCONSUB, THTRALACC, THNSCAN, THTRALSUB, THNDROPSUB, THCASSALLSUB, THCONGSAS, THCONGSASSUB, THCONGSHO, THCONGSHOSUB, THNRELCONG, THNRELCONGS UB CELTCHFP Primary band TFESTPGSM, TFESTPGSMSUB, TFCONGPGSM, TFDROPPGSM, TFDROPPGSMSUB, TFTRALPAC C, TFTRALPACCSUB, Counters on cell level for monitoring selected performance indicators separately for channel group zero. See Section 5.7.17 on page 81. CHGRP0F 20 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Object Type Short Description STS Counters Counters on cell level for monitoring selected performance indicators separately for channel group zero. See Section 5.7.17 on page 81. CHGRP0SQI Speech quality supervision downlink for channel group zero TSQ0GOODDL, TSQ0ACCPTDL, TSQ0BADDL, TSQ0AHGOODDL, TSQ0AHACCPTDL, TSQ0A HBADDL, TSQ0AFGOODDL, TSQ0AFACCPTDL, TSQ0AF BADDL, TSQ0AWGOODDL, TSQ0AWACCPTDL and TSQ0AWBADDL. CLRATECHG To monitor Dynamic FR/HR mode adaptation. AMRABHOSUCFRHR, NAMRABHOSUCFRHR, HOATFRHRAMR, HOATFRH RNAMR, HOSUCFRHRAMR, HOSUCFRHRNAMR, HOATH RFRAMR, HOATHRFRNAMR, HOSUCHRFRAMR, HOSUCHRF RNAMR, ATAMRLDHRFRHO, SUCAMRLDHRFRHO, ATNAMRLDHRFRHO, SUCNAMRLDHRFRHO, HOATFRHRAW, HOSUCFRHRAW and AWABHOSUCFRHR. Counters on cell level for monitoring the distribution of downlink and uplink RXQUAL values. See Section 5.6.9 on page 66. CLSDCCH, CLSDCCHO Traffic measurements for SDCCH per cell. SDCCH counters (O=OL =>SUB) CSCSTCONG, CSCSOPTCONG, CESTCHACTIV, CESTIMMASS, CCALLS, CCONGS, CTCONGS, CTRALACC, CNSCAN, CNDROP, CNUCHCNT, CAVAACC, CAVASCAN, CMSESTAB, CNRELCONG, CCALLSSUB, CCONGSSUB, CTCONSUB, CTRALSUB, CNSCANSUB, CNUCHSUB, CAVASUB, CAVASCANSUB, CMSESTABSUB, CNRELCONGSUB, CLUNDROP, CLUMSESTAB, CLUMSESTABSU B. CLSMS Short Message Service counters CSMSDWN, CSMSUP, TSMSDWN, TSMSUP CHGRP0H CLRXQUAL 216/1553-HSC 103 12/16 Uen E | 2010-11-10 21 User Description, Radio Network Statistics Object Type Short Description STS Counters CLTCH Traffic channel connections counters TNUCHCNT, TNUCHSUB, TAVAACC, TAVASCAN, TAVASUB, and Packet ABIS Overload counter TAVASCANSUB, TASSALL, for CS. TCASSALL, NONAVFCH, NONAVHCH, TASSATT, TCHSIG, OVERLOADREJCON. CLTCHEAS Counters for Enhanced AMR Coverage. EASULACTMREP, EASULC APMREP, EASDLACTSBL, EASDLCAPSBL CLTCHDRF Counters for dropped connections on all FR traffic channels TFDISFERDL/UL/BL, TFDISFER DLSUB/ULSUB/BLSUB,TFDISTA, TFDISSS1...5, TFSUDLOS, TFSU DLOSSUB, TFDISSDL/UL/BL, TFDISSDLSUB/ULSUB/BLSUB, TFDISQADL/UL/BL, TFDISQADLS UB/ULSUB/BLSUB CLTCHDRAF Counters for dropped connections on AMR full rate TFDISFERDLA/ULA/BLA, TFDISFERDLSUBA/ULS UBA/BLSUBA, TFDISTAA, TFSUDLOSA, TFSUDLOSSUBA, TFDISSDLA/ULA/BLA, TFDIS SDLSUBA/ULSUBA/BLSUBA, TFDISQADLA/ULA/BLA, TFDISQA DLSUBA/ULSUBA/BLSUBA CLTCHDRH Counters for dropped connections for all HR traffic channels THDISFERUL/DL/BL, THDISFERULSUB/DLSUB/BLSUB, THDISTA, THDISSS1...5, THSUDLOS, THSUDLOSSUB, THDISSDL/UL/BL, THDISSDLSUB/ ULSUB/BLSUB, THDISQADL/UL/B L, THDISQADLSUB/ULSUB/BLSUB CLTCHDRAH Counters for dropped connections on AMR half rate THDISFERULA/DLA/BLA, THDISFERULSUBA/DLS UBA/BLSUBA, THDISTAA, THSUDLOSA, THSUDLOSSUBA, THDISSDLA/ULA/BLA, THDIS SDLSUBA/ULSUBA/BLSUBA, THDISQADLA/ULA/BLA, THDISQA DLSUBA/ULSUBA/BLSUBA CLTCHFV1 Counters for TCH utilization for Speech Version 1 FR TFV1CALLS, TFV1CALLSSUB, TFV1TCONGS, TFV1TCONSUB, TFV1TRALACC, TFV1NSCAN, TFV1TRALSUB, TFV1CONGSAS, TFV1CONGSASSUB, TFV1CONG SHO, TFV1CONGSHOSUB 22 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Object Type Short Description CLTCHFV2, CLTCHHV1, CLTCHFV3, CLTCHHV3 and CLTCHFV5 Counters for TCH utilization and SCC capacity locks statistics for optional speech codecs (Counters in CLTCHFV2 shown here) TFV2CALLS, TFV2CALLSSUB, TFV2TCONGS, TFV2TCONSUB, TFV2TRALACC, TFV2NSCAN, TFV2TRALSUB, TFV2CONGSAS, TFV2CONGSASSUB, TFV2CO NGSHO, TFV2CONGSHOSUB, TFV2TCONGSCC. CLTCHFV3C Counters for codec mode utilization for AMR full rate TFV3CM1UL, TFV3CM2UL, TFV3CM3UL, TFV3CM4UL, TFV3CM1DL, TFV3CM2DL, TFV3CM3DL, TFV3CM4DL CLTCHHV3C Counters for codec mode utilization for AMR half rate THV3CM1UL, THV3CM2UL, THV3CM3UL, THV3CM4UL, THV3CM1DL, THV3CM2DL, THV3CM3DL, THV3CM4DL CLTCHFV5C Codec Mode Utilization measurements for TCH/F Speech Version 5 on cell level. TFV5CM1UL, TFV5CM2UL, TFV5CM3UL, TFV5CM1DL, TFV5CM2DL, TFV5CM3DL DOWNTIME Downtime statistics TDWNACC, TDWNSCAN, BDWNACC. IDLEUTCHF (4 object types) Counters for idle traffic channels (H=HR or F=FR) per subcell (U=UL,O=OL) NOACCUF, ITFUSIB1...5 PREEMP Preemptive allocation attempts VGCSPH, HOATTPH, FAILPH, DISPH. RANDOMACC Random access CNROCNT, RAACCFA, RAEMCAL, RACALRE, RAANPAG, RAOSREQ, RAOTHER, RATRHFAEMCAL, RATRHFAREG, RATRHFAANPAG, RATRHFAOTHER RNDACCEXT Random access, extended RACALR1...2, RAAPAG1...2, RAAPOPS, RAORSPE, RAORDAT Table 6 STS Counters A Summary of Object Types Related to the Radio Network and Neighboring Cell Relations. Object Type Short Description STS Counters NCELLREL, NECELLREL Handover counters (internal/extern al) HOVERCNT, HOVERSUC, HORTTOCH NICELASS, NECELASS Counters for handovers at assignment (internal/external) HOASBCL, HOASWCL, HOSUCBCL, HOSUCWCL 216/1553-HSC 103 12/16 Uen E | 2010-11-10 23 User Description, Radio Network Statistics Object Type NICELHO, NECELHO NICELHOEX, NECELHOEX 4.5 Short Description STS Counters Counters for handover decisions (internal/external) HOTOLCL, HOTOKCL, HOTOHCS, HOUPLQA, HODWNQA, HOEXCTA, HODUPFT Handover attempts at high handover rate and classifying serving cell (internal/external) HOATTHR, HOSUCHR, HOATTLSS, HOATTHSS Object Types Used for GPRS The list below shows the BSC object types related to radio network statistics for GPRS. A brief explanation and the counters in the object type are presented along with the object types. Table 7 A Summary of Object Types Related to GPRS and the Radio Network on BSC, GPH RP and Cell Level. Object Type Short Description Counters for GPRS on BSC level. Mixed usage. AQMDELIVDATA, AQMRECDATA, ALLPDCHPCUFAIL, DISCDL, DISCUL, PAGCSBSC, PAGCSCONG, PAGPSBSC, FAILMOVECELL, NACCPCO, ESUTONRM, ESUDLTBF, DELRELTONRM, DELRELDLTBF, EXULTIP, EXULNRM, GSL0040, GSL4160, GSL6180, GSL8190, GSL9100, GSLMAX, GSLUTIL, GSLSCAN, ALLPDCHPCUATT. Counters for GPRS on BSC level. Currently used to monitor GPH RP load per PCU and NC2 performance, respectively. RPP0040, RPP4160, RPP6180, RPP8190, RPP9100, NC2ORDER, NC2CONF, NC2PCO, G2GPH0040LOAD, G2GPH4160LOAD, G2GPH61 80LOAD, G2GPH8190LOAD, G2GPH9100LOAD. BSCGPRS BSCGPRS2 STS Counters BSCQOS QoS monitoring on BSS level. Note See Section 6.17.6 on page 173. NOT to be used to monitor the overall user IP throughput for the BSC. CCCHLOAD Number of CS and PS immediate assignment and immediate assignment reject messages sent on the CCCH. Cell level. 24 CSIMMASS, DISCIMMASS, REJCSIMMASS, PSIMMASS, REJPSIMMASS. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Object Type Short Description STS Counters Counters on cell level to monitor the performance of EIT with respect to the Push-To-Talk service. EITDLGTBF, EITULGTBF, EITDLETBF, EITULETBF, EITTBFSCAN, Q1TDDLEIT, Q2TDDLEIT, Q3TDDLEIT, Q1TDULEIT, Q2TDULEIT, Q3TDULEIT, RLCGDLEITSCHED, RLCGULEITSCHED, RLCEDLE ITSCHED, RLCEULEITSCHED, EITDLGPDCH, EITULGPDCH, EITDLEPDCH, EITULEPDCH, EITDLBPDCH, EITULBPDCH. Counters on cell level to monitor the performance of EIT with respect to the Push-To-Talk service. ACREQEIT, ACREJEIT, RLCG DLVOLEIT, RLCGULVOLEIT, RLCEDLVOLEIT, RLCEULVOLEIT, LLCVOLDLEIT, LLCVOLULEIT. Counters for GPRS on cell level. Mixed usage including PDCH allocation counters and radio link quality measures for all uplink transfers and downlink CS-1/2 mode transfers. ALLPDCHACC, ALLPDCHACTACC , ALLPDCHPEAK, ALLPDCHSCAN, PAGCSBVCI, PPAGCSBVCI, PCHALLATT, PCHALLFAIL, PREEMPTPDCH, PDRAC, PDPRAC, CS12ULSCHED, CS12DLSCHED, CS12ULACK, CS12DLACK, MC19ULSCHED, MC19ULACK, DLTBFEST, FAIL DLTBFEST, TBFPREEMPPEST, PREEMPTTBF, MOVECELLTBF, CELLMOVED, MC19QULSCHED, MC19QULACK, MSESTDLTBF, LDISEST, FAILDLANSW. CELLEIT CELLEIT2 CELLGPRS Counters to monitor number of RLC data blocks used for EGPRS mode TBFs at optimum coding scheme according to LQC algorithm. Counters to monitor DL TBF establishment. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 25 User Description, Radio Network Statistics Object Type Short Description Counters to monitor GPRS on cell level. • IP transfer interrupts DL (IP buffer discards) and IP transfer interrupts UL • Load on PRACH capacity • Load on PPCH CELLGPRS2 • On-demand PDCH preemption attempts and failures • Number of RLC data blocks used for CS-1/2/3/4 and EGPRS mode TBFs. STS Counters LDISTFI, LDISRR, LDISOTH, PSCHREQ, PREJTFI, PREJOTH, IAULREL, FLUDISC, FLUMOVE, PCHRREQ, PCHRZRETRY, PCHROPRETRY, PCHRSCAN, PAGDISCPPCH, PAGCSONPPCH, PAGPSONPPCH, PMTATT, PMTREF, CS14DLSCHED, MC19 DLSCHED, PREEMPTULREL, OTHULREL, MSESTULTBF, CS14DLACK, MC19DLACK, CS14QDLSCHED, CS14QDLACK, MC19QDLSCHED, MC19QDLACK, CRSULREL. • Counters to monitor number of RLC data blocks used for CS-1/2/3/4 and EGPRS mode TBFs at optimum coding scheme according to LQC algorithm. • Cell Reselections UL. Counters for GPRS on cell level. GPRS availability, IP latency and IP data volume and rejected new PS session setups due to packet Abis congestion. CELLGPRS3 CELLGPRS4 26 Counters for counting the user data volume generated by SAIC capable mobiles Counters for GPRS on cell level. Throughput counters based on MS EGPRS/GPRS capability and number of counters for active GPRS and EGPRS users. PMTCSABCONG, PMTPSABCON G, GPRSCELLAVA, AVAILRBLKS, USEDDLRBLKS, USEDULRBLKS, GPRSAVA, ACCEGEXTIPLAT, ACCEGNOEXTIPLAT, ACCGEXTIPLAT, ACCGN OEXTIPLAT, EGEXTIPLAT, EGNOEXTIPLAT, GEXTIPLAT, GNOEXTIPLAT, DLSTRVOL, DLINTBGVOL, ULINTBGVOL, DLGMMVOL, ULGMMVOL, PREEMPDCHVG, PREEMTBFVG, LCCLRELBUSYHI3, DLSAICVOL, ULSAICVOL, PREJABISCONG, ACCEGRLIPLAT, EGRLIPLAT. DLMSGTHR, ULMSGTHR, DLMSEGTHR, ULMSEGTHR, DLMSGDATA, ULMSGDATA, DLMSEGDATA, ULMSEGDATA, IRATPREV, ACTGUSE, ACTEUSE, ACTUSESCAN. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Object Type Short Description STS Counters Counters for GPRS for the overlaid subcell. Mixed usage. ALLPDCHSCANSUB, PREEMPTP DCHSUB, ALLPDCHACCSUB, ALLPDCHACTACCSUB, MC19DLSCHEDSUB, MC19DLACKSUB, MC19ULS CHEDSUB, MC19ULACKSUB, CS14DLSCHEDSUB, CS14DLACKSUB, CS12DLS CHEDSUB, CS14ULACKSUB, CS12ULSCHEDSUB, LDISRRSUB, IAULRELSUB, CS14QDLSCH EDSUB, CS14QDLACKSUB, MC19QDLSCHEDSUB, MC19QDLACKSUB, MC19QU LSCHEDSUB, MC19QULACKSUB, CRSULRELSUB. CELLQOSG IP throughput on cell level for Basic and GPRS mode TBFs. See Section 6.3 on page 99. CELLQOSEG IP throughput on cell level for EGPRS mode TBFs. See Section 6.3 on page 99. CELLQOSS IP throughput on cell level for streaming. See Section 6.3 on page 99. Counters on cell level for streaming negotiation for resources. See Section 6.8 on page 122. DELSTRTBF Counters on BSC level to assist with the setting of parameters for TBF “keep alive” mechanisms related to streaming. STARTSTRTBF, STARTCO NTSTRTBF, PENDSTRTBF, PENDCONTSTRTBF. Counter to monitor the GPH processor load per RP (for all types of RP platforms in the PCU). RPPLOAD. EMGPRS GPH Overload Protection function counters per BSC. LCCELLMOV, LCCELLMOVREJ, LCHIRPPLOAD, LCPARREJ, LCMSSUPRFC, LCRELBUSYHI3, LCRELIDLEHI3, LCLRPARREJ. CELLGPRSO CLQOSSCON and CLQOSSCO N2 GPHLOADREG GPRSCAP RLINKBITR TRAFEEVO Packet Switched Capacity Locks Counters per BSC GBTRAFVOL, GBTRAFPEAK, GBTIMECONG. Radio link quality measures for downlink CS-1/2/3/4 and EGPRS mode transfers on cell level. See Section 6.9 on page 124. Traffic load measurements for Edge Evolution TBFDCDLCAP, TRAFDCDLTBF, MAXDCTSDL, MUTILDCDL, TRAFEEVOSCAN, TSDCDL. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 27 User Description, Radio Network Statistics Object Type Short Description STS Counters TRAFDLGPRS GRPS/EGRPS traffic load counters for the downlink on cell level. See Section 6.10 on page 138. TRAFULGPRS GRPS/EGRPS traffic load counters for the uplink on cell level. See Section 6.10 on page 138. TRAFGPRS2 Multislot utilization counters for the downlink on cell level. See Section 6.13 on page 153. TRAFGPRS3 Multislot utilization counters for the uplink on cell level. See Section 6.13 on page 153. 4.6 Object Types for DTM The list below shows the BSC object types related to the radio network statistics for DTM. Table 8 Object Type CLDTMEST 28 Short Description Counters on cell level for DTM connection set-up attempts and successful establishments per channel service. STS Counters TDTMALLOCATT, TDTMATT, TFSPV1DTMSUC, TFSPV2DTMSUC, TFSPV3DTMSUC, THSPV1DTMSUC, THSPV3DTMSUC, TFSPV5DTMSUC. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS Object Type Short Description STS Counters Counters on cell level for the multislot utilization for DTM TBFs. Also DL IP buffer discards and UL accessibility/retainability for DTM connections. MSESTULDTMTBF, DTMDLTBFSCAN, DTMUL TBFSCAN, DTMDLMUTIL, DTMULMUTIL, DTMDLMAXTS, DTMULMAXTS, DTMFILDIS, DTMRRLDIS, DTMOTHLDIS, DTMULSUCRES, DTMULTFIFAILRES, DTMULOTHFAILRES, DTMULRELLOST, DTMPREEMPTULREL, DTMOTHULREL, DTMAC TGUSE, DTMACTEUSE, DTMACTUSESCAN, DTMULABISFAILRES. Counters for number of active GPRS and EGPRS users in DTM CLDTMPER Counters on cell level for IP data volume and IP throughput for DTM connections. CLDTMQOS 4.7 DTMGULTHP, DTMGDLTHP, DTMEGULTHP, DTMEG DLTHP, DTMULGDATA, DTMDLGDATA, DTMULE GDATA, DTMDLEGDATA, DTMULSTRDATA, DTMDLSTRDATA. Object Types for GSM to UTRAN The list below shows the BSC object types related to the radio network statistics for interaction between GSM and UTRAN. Table 9 Object Type Short Description GSM to UTRAN handovers NUCELLREL 4.8 STS Counters HOATTSHOULDUTRAN, URGHOVERUTRAN, SUCURGHOUTRAN, HOVERCNTUTRAN, HOVERSUCUTRAN, HORTTOCHUTRAN, HOREQCNTUTRAN. Main Changes in Ericsson GSM System G10B/BSS G10B There are a number of new STS object types and counters implemented. Some of the counters give enhanced possibilities for performance monitoring and some are for monitoring of new features. A complete listing of all counter 216/1553-HSC 103 12/16 Uen E | 2010-11-10 29 User Description, Radio Network Statistics related changes, including secondary impacts on legacy counters, can be found in BSS G10B Network Impact Report. Object types with modified usage: • None. Object types with new counters: The following counters for Abis over IP have been added to the object type ABISIP • IPOVLCSREG • IPOVLPSREG The following counters for A over IP have been added to the object type AGWTRAF: • SENTMUXPKTMBS • SENTMUXPKTMBT • KBRECMUX • KBSENTMUX • SENTSPFMUX • RECSPFMUX • SENTSPFPCMMUX • RECSPFPCMMUX • SENTDFPCMMUX • RECDFPCMMUX The following counters for SCC Capacity locks have been added to the corresponding object type CLTCHFV2, CLTCHFV3, CLTCHFV5, CLTCHHV1 and CLTCHHV3, respectively: • TFV2TCONGSCC • TFV3TCONGSCC • TFV5TCONGSCC • THV1TCONGSCC • THV3TCONGSCC The following counter has been added to the object type GPHLOADREG: 30 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS • LCLRPARREJ The following counters for Abis optimization have been added to the object type SUPERCH2: • SCOVLCSREG • SCOVLPSREG New object types: Counters for Capacity Locks for SCC statistics, Optional speech codec capacity observability The following new counters for Capacity Locks for SCC statistics regarding Optional speech codec capacity observability have been introduced in the new object type BSCSCCCL: • TCONGAFR • TCONGAHR • TCONGAWB • TCONGEFR • TCONGHR • TRAFAFR • TRAFAHR • TRAFAWB • TRAFEFR • TRAFHR • TRAFSCAN Counters for dynamic BTS and MS power control. The following new counters for dynamic BTS and MS power control .have been introduced in the new object type CELLDYNPC. The counters contain the accumulated initial power down regulation in dB for BTS and MS power control respectively. • BSINITDREGHO • MSINITDREGHO Counters for Managed Object Multi Carrier Transmitter Receiver 216/1553-HSC 103 12/16 Uen E | 2010-11-10 31 User Description, Radio Network Statistics The following counters have been introduced in the new object type MOMCTR. These counters show Multi Carrier Power Amplifier (MCPA) power utilization and service quality impact: • • BPWRO100 BPWR90100 • BPWR8090 • BPWR7080 • BPWR6070 • BPWR5060 • BPWR0050 • NUMTCHB • NUMTCHBRED • ACCTCHBREDDB • NUMPDCHB • NUMPDCHBRED • ACCPDCHBREDDB • NUMOB • NUMOBRED • ACCOBREDDB • NUMSDCCHB • NUMSDCCHBRED • ACCSDCCHBREDDB Counters for Capacity Lock on A over IP The following new counters for capacity lock for the A over IP interface have been introduced in the new object type AOIPCAP: 32 • AOIPATT • AOIPCONGCL • AOIPCONGOTH • AOIPPEAK 216/1553-HSC 103 12/16 Uen E | 2010-11-10 STS • AOIPTCONG Object types with changed counter behavior: ABISIP The following counters in Object type ABISIP has been altered as specified. • IPOVLL1: Altered to measure number of seconds when level 1 actions have been taken to solve overload on Abis over IP. • IPOVLL2: Altered to measure number of seconds when level 2 actions have been taken to solve overload on Abis over IP. GPHLOADREG Due to changes in the GPH Load Control mechanism the behavior of the STS counter LCHIRPPLOAD is changed. • LCHIRPPLOAD: This counter is stepped each minute when more than 2% of all Channel Requests are rejected due to load regulation or overload protection. GPHLOADREG and CELLGPRS3 The following counters will not be used any longer due to changes in the GPH Load Control mechanism. • LCCLRELBUSYHI3: Not used any longer. • LCRELBUSYHI3: Not used any longer. • LCRELIDLEHI3: Not used any longer. CELLGPRS2 Due to changes in the GPH Load Control mechanism the behavior of STS counter PREJOTH is changed. • PREJOTH: Will also include Packet Access Requests rejected due to GPH Load Control mechanism, that is, the rejects that are counted by the new counter LCLRPARREJ. CELLGPRS, CELLGPRS2, GPHLOADREG and BSCGPRS The following counters will be affected by changed limits for when to initiate move of cell due to GPH processor load: LCCELLMOV, LCCELLMOVREJ, CELLMOVED, FAILMOVECELL, and MOVECELLTBF. The counters TBFPREEMPEST, PREEMPTTBF and PREEMPTULREL will no longer include stepping due to GPH Overload Protection. Object types removed: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 33 User Description, Radio Network Statistics • 34 None 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring 5 GSM Radio Network Performance Monitoring 5.1 Introduction This chapter contains important performance indicators within the radio part of Ericsson's GSM system. The main focus is on how to monitor the GSM radio network performance in the areas of accessibility, retainability and speech quality. Resource utilization is briefly mentioned together with some more general traffic measurement statistics. The focus is on subscriber perceived quality. 5.2 Accessibility The accessibility area in a radio network covers random access, congestion on SDCCH and TCH and call setup. Retainability Retainability covers the ability to keep up a call. Call drop rate, handover performance and interference are included in this area. Speech Quality In GSM networks the speech quality is very difficult to measure. However, the Speech Quality Supervision function (SQS) provides STS with counters, giving an objective measure of the speech quality. TEMS has support for the same algorithm, but is in general not an efficient method to get information about the speech quality in the whole network. Definitions and Explanations The examples in this chapter are usually given for one of the alternatives of channels, speech coding, subcells etc. such as TCH/FR/UL (Full Rate Traffic Channels in the Underlaid subcell). STS counters and user formulas are structured and named in the same way for HR channels, overlaid subcells etc. where applicable. A user formula is composed of several STS counters. The formulas can be used to simplify the comparison between cells and to relate different counters. For some important counters information is given about how the counter is stepped. Counters are written as they appear in STS while the formulas defined and used have one or several underscores ( _ ) in their names. The following parameter is fetched from STS although no counter: Ceil (expression) means that the result of the expression within the parenthesis should be rounded to the closest higher integer. PERLEN 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Measurement period length used in STS (minutes). 35 User Description, Radio Network Statistics 5.3 General Traffic Information The main scope with this area is to check the traffic on BSC and cell level. On cell level also congestion is important. This is discussed in Section 5.4.8 on page 45. By monitoring the TCH traffic load on BSC level a comparison can be made with planned or installed capacity. By ranking cells according to traffic level, priority can be given to problem cells with a high amount of traffic. The following counters can be found in the object types CELTCHF and CELTCHH for full- and half-rate respectively and also in CLTCH. TFTRALACC Traffic level accumulator for full-rate TCH. The corresponding counter for half-rate is THTRALACC. TFNSCAN Number of accumulations of traffic level counter for full-rate TCH. The corresponding counter for half-rate is THNSCAN. TAVAACC Available Basic Physical Channels (BPCs) for traffic channels accumulator. Also available for overlaid subcell, TAVAACCSUB. TAVASCAN Number of accumulations of available BPCs for traffic channels counter. Also available for overlaid subcell, TAVASCANSUB. The following formula, TFtraff, shows the average TCH full-rate traffic level in a cell (underlaid + overlaid) in Erlang or, more accurate, the mean number of allocated full-rate TCH channels. T F traff = TTFFTNRALACC [Erlang] SCAN Equation 1 TCH Full-Rate Traffic Level in a cell The following formula, T_TRAFF, shows the average level of all TCH traffic in a cell (underlaid + overlaid) in Erlang or, more accurate, the mean number of allocated TCH channels. T traff RALACC T HT RALACC + T HNSCAN [Erlang] = TTFFTNSCAN Equation 2 Total (FR+HR) TCH Traffic Level in a cell The value can be calculated for the whole BSC by adding all cells together. The traffic can also be calculated for cells and subcells. In the subcell case there is a specific counter for overlaid subcell TCH traffic, THTRALSUB and TFTRALSUB (half- and full-rate respectively). The values for underlaid cell can be obtained by subtracting the value of the overlaid from THTRALACC or TFTRALACC respectively. A similar formula can be used for SDCCH traffic using the 36 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring counters CTRALACC and CNSCAN in the object types CLSDCCH (underlaid + overlaid) and CLSDCCHO (for statistics in overlaid cells). Location area border cells can be expected to have a higher SDCCH load than other cells. The traffic level can be compared with the number of available number of Basic Physical Channels (BPCs) to get information about subscriber behavior or the need for new hardware. This calculation can be made on both BSC and cell level. The channel utilization for a network without any half-rate traffic can be written as: T CHutil = T F traff 3 T AV ASCAN 3 100 [%] T AV AACC Equation 3 TCH Channel Utilization of Available TCH Channels in a Full-Rate Network The formula can also be used for SDCCH (object types CLSDCCH and CLSDCCHO) and for subcells. By comparing the installed channel resources with the actually used the efficiency of the resource planning can be checked. Usually there are areas with low traffic despite a high number of installed TRXs. By using these TRXs elsewhere more traffic can be handled by the system. However, be very careful before moving TRXs as the capacity might be planned for fairs etc. The mean holding time for SDCCH or TCH is obtained by taking the number of MS establishments into account when calculating the traffic. The following counters are situated in the object types CELTCHF, CELTCHH, CLSDCCH and CLSDCCHO. TFMSESTB Successful MS establishment on TCH full-rate. The corresponding counter for half-rate is THMSESTB. These counters are sums of both overlaid and underlaid. To get overlaid only, the TFMSESTBSUB or THMSESTBSUB can be used. CMSESTAB Successful MS establishment on SDCCH. This counter is a sum of both overlaid and underlaid. To get overlaid only, the CMSESTABSUB can be used. CLUMSESTAB Successful MS establishment on SDCCH. This counter is a sum of both overlaid and underlaid. To get overlaid only, the CLUMSESTABSUB can be used. The counters CLUMSESTAB and CLUMSESTABSUB are only incremented in case of location area update, while CMSESTAB and CMSESTABSUB are incremented for all traffic cases. T F meanh = T F traff 3 P ERLEN 3 60 [ s] T F MSEST B Equation 4 TCH Mean Holding Time In Seconds on Full-Rate Channels 216/1553-HSC 103 12/16 Uen E | 2010-11-10 37 User Description, Radio Network Statistics TFtraff is the full-rate TCH traffic and PERLEN is the period length of the measurement used in STS given in minutes. The expression can be modified to contain the mean holding time for both half- and full-rate. The corresponding formula for SDCCH uses the counter CMSESTAB (object type CLSDCCH). CLSDCCHO contains counters for the overlaid cell statistics only. The SDCCH mean holding time should be as short as possible to decrease the risk for SDCCH congestion. The values for TCH mean holding time must not be mistaken for call mean holding time. The call can be handed over to a new TCH which causes the TCH holding time to be shorter than the call length. To get a rough value of the average call length on BSC level, TFMSESTB can be exchanged for TFCASSALL in the formula above. Please note that the calls handed over to or from external cells are affecting the values. 5.4 Accessibility 5.4.1 General The accessibility is defined as the ability to set up a call. This ranges from the arrival of the random access burst to the event TCH assignment. 5.4.2 Availability The channel availability is very difficult to measure despite counters such as TAVAACC, number of available TCHs. This is due to the fact that TNUCHCNT, number of defined TCHs, depends on whether the number is system defined or operator defined. System defined means that the number of TCHs is based on the number of allocated frequencies instead of the number of installed TRXs. Operator defined means that the number of defined TCH channels is calculated as the required number of Basic Physical Channels (BPCs) defined by command (parameter NUMREQBPC) for the cell/channel group minus the number of BPCs used for BCCH and SDCCH in the cell/channel group. This is especially useful when synthesizer hopping is used (more frequencies than hardware). The equation below can be used to calculate the number of available TCHs of total number of defined TCHs but the result will not be correct if the feature Adaptive configuration of logical channels is used. If Adaptive configuration of logical channels is activated the number of TCHs might change in the cell depending on the SDCCH traffic level. If the number of TCHs are operator defined or if synthesizer hopping is not active the following formula can be used: 38 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring T avail = T AV AACC 3 100 [%] T AV ASCAN 3 T NUCHCNT Equation 5 Available TCHs of Total Number of Defined TCHs Note that if BTS power savings is used the formula for available TCHs of Total Number of Defined TCHs must be compensated as follows: T avail = 100 3 ((T AV AACC=T AV ASCAN ) + 8 3 BT Sps 0 SDCCH=8) [%] T NUCHCNT W here : BT Sps = (NU MT RXOF F P S=NUMT RXSCAN ) SDCCH = (CNUCHCNT 0 (CAV AACC=CAV ASCAN )) Equation 6 Note: Available TCHs of Total Number of Defined TCHs when using BTS power savings If there are TRXs in operation which have no TCH channels configured the TCH availability formula for BTS power savings may show to high values. This is due to that when BTS power savings turn off a TRX which have no TCH channels defined the counter NUMTRXOFFPS will be stepped while TNUCHCNT will not step as this counter only steps for defined TCH channels. For BTS Power Savings counter descriptions please see chapterSection 5.4.3 BTS Power Savings Counters on page 40. Other useful indicators for availability are the counters for cell downtime statistics in the object type DOWNTIME. TDWNACC The counter is stepped every tenth second if there are no TCHs in IDLE or BUSY state in the cell and the cell state is ACTIVE. TDWNSCAN The counter is stepped every tenth second when the cell state is ACTIVE. BDWNACC Accumulated number of scans of the cell where the BCCH was unavailable. The total cell downtime in percentage is then expressed as: T dwn = T DW NACC T DW NSCAN Equation 7 3 100 [%] TCH Downtime Percentage 216/1553-HSC 103 12/16 Uen E | 2010-11-10 39 User Description, Radio Network Statistics 5.4.3 BTS Power Savings Counters The counters described in this section belong to Object Type CELLBTSPS and are used for measurements for BTS Power Savings. The counters described are accumulated for all TRXs in a cell. 5.4.4 TRXOFF Number of times a TRX (no matter which one in the cell) has been disabled because of BTS Power Savings. TRXON Number of times a TRX (no matter which one in the cell) has been enabled because of BTS Power Savings. NUMTRXOFFPS Number of disabled TRXs because of BTS Power Savings. The number of TRXs that are currently disabled because of BTS Power Savings is scanned every 10 s and the value is accumulated to the counter. NUMTRXSCAN Number of scans (accumulations) to counter NUMTRXOFFPS. This counter is incremented by one every time the number of TRXs that are currently disabled because of BTS Power Savings is scanned. Paging The object type CELLPAG consists of two counters related to paging on cell level. The location area dimensioning guideline, see Reference [5], and the idle mode behavior user description Reference [26] contains a full description of how to use the counters in object type CELLPAG to determine if there is a congestion problem on the PCH (from the ratio of pages discarded in the BTS to pages received in the BTS) and how to calculate the load on the CCCH. The counters are only for the PCH queue in the BTS. Pages on PPCH are not queued in the BTS: PAGPCHCONG Number of paging messages discarded due to full cell paging queue. PAGETOOOLD Number of paging messages discarded due to being too long in the paging queue. At the point when a page is taken from the paging queue, its age is calculated and compared to the BTS parameter AGE-OF-PAGING (the parameter is set to 5 seconds in Ericsson BSS). If it is too old, it is discarded and PAGETOOLD is incremented. The object type BSC consists of two counters related to paging on BSC level: 40 TOTPAG Number of paging messages received from the MSC. TOTCONGPAG Number of paging messages discarded due to lack of capacity in the BSC or due to congestion in the BSC paging queues or due to no Data Link Individual is 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring available for a paging request taken from the paging queue. The rate of discarded paging messages can then be expressed as: PAGfail = T OT CONGP AG 3 100 [%] T OT P AG Equation 8 Rate of Discarded Paging Messages in the BSC Statistics from the MSC are outside the scope of this document. However, the Ericsson MSC provides some further counters related to paging. The object type LOCAREAST can for instance be used to calculate the paging success rate for a Location Area (LA): PLsuc1 = NLAP AG1RESUCC + NLAP AG2RESUCC 3 100 [%] NLAP AG1LOT OT Equation 9 Successful First and Repeated Page Attempts of Total Number of First Page Attempts Related to the paging success rate is the Location Update (LU) performance. The following ratio can be calculated: LAluSUC = NLALOCSUCC 3 100 [%] NLALOCT OT Equation 10 Successful LU Attempts of Total Number of LU Attempts on LA Level Some useful counters in the MSC object type LOCAREAST: NLAPAG1LOTOT Number of first page attempts to an LA. NLAPAG2LOTOT Number of repeated page attempts to an LA. NLAPAG1RESUCC Number of page responses to first page to an LA. NLAPAG2RESUCC Number of page responses to repeated page to an LA. 5.4.5 NLALOCTOT Total number of LU attempts in the LA. NLALOCSUCC Number of successful LUs in the LA. Random Access The object types RANDOMACC, RNDACCEXT and CELLGPRS contain the counters for Random Access (RA) reasons and performance. The number of successful and failed random accesses are registered and information about the distribution of the reasons for random access is also available. A failed random access burst does not necessarily lead to a call setup failure, as the 216/1553-HSC 103 12/16 Uen E | 2010-11-10 41 User Description, Radio Network Statistics MS sends many RA bursts each time it tries to connect to the network. A high number of RA failures might be caused by bad BSIC planning or interference. RAACCFA Number of Failed Random Accesses. This counter is incremented for a Random access received with too high TA, values that are not used or in case of "software file congestion" (i.e. when the internal storage area in the BSC is full which is a very rare case only occuring at very high loads). CNROCNT Number of Accepted Random Accesses. This counter is also incremented for TRXT connections. PDRAC The counter value is incremented when a 44.058 CHANNEL REQUIRED containing 44.018 CHANNEL REQUEST with establishment cause "One Phase Packet Access" or "Single Block Packet Access" is received on RACH. The following formula can be used to calculate the random access failure rate: RAfail = RAACCFA +RAACCFA CNROCNT + PDRAC 3 100 [%] Equation 11 The Random Access Failure Rate There are also some load related rejects covered by object type LOADREG. 5.4.6 Call Attempts The call attempts go from the successful random access to TCH via an SDCCH. Some of the counters connected with this process are as follows. They are situated in the object types CLSDCCH, CLSDCCHO, CLTCH and CELTCHF/H. 42 CCALLS Channel allocation attempt counter (on SDCCH). CMSESTAB Successful MS channel establishments on SDCCH. CCONGS Congestion counter for underlaid subcell. Stepped per congested allocation attempt. The counter for overlaid subcell is CCONGSSUB. CESTCHACTIV Number of SDDCH establishment failure that occurs under channel allocation and channel activation. Note that this counter is stepped also in case of SDCCH congestion. CESTIMMASS Number of SDCCH establishment failure due to time-out after sending Immediate Assignment, timer T3101 expired. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring TFCASSALL Number of assignment complete messages for all MS power classes in underlaid subcell, full-rate. There is also an identical counter for overlaid subcells, TFCASSALLSUB. There are corresponding counters for half-rate, THCASSALL and THCASSALLSUB, respectively. TASSATT Number of first assignment attempts on TCH for all MS power classes. Both successful and unsuccessful attempts are counted in the target cell. TASSALL Number of first assignment attempts on TCH for all MS power classes. Successful attempts are counted in the target cell and failed attempts are counted in the serving cell. The serving cell is the cell where the mobile station was tuned to an SDCCH or TCH for signalling. TCASSALL Number of assignment complete messages on TCH for all MS power classes. The counter CCALLS can be stepped several times during a call setup, due to for instance congestion or several received Random Accesses (RAs) from a mobile. This could result in very high values for these counters in problem cells and should be considered with care in those cases. The formula below has compensated for the attempts at congestion. The number of SDCCH establishments in relation to the number of seizure attempts (when no SDCCH congestion) can be calculated as follows: Sest = CMSEST AB 3 100 [%] CCALLS 0 (CCONGS + CCONGSSUB ) Equation 12 SDCCH Establishment Success Rate for Over- and Underlaid Subcell The expression measures the success rate for establishing an SDCCH channel for valid random accesses that have been received. The reasons for SDCCH establishment failures can be analyzed by looking at the counters CCONGS, CCONGSUB, CESTCHACTIV and CESTIMMASS. The following expression measures the performance of assignments (change from SDCCH to TCH). By compensating for handover during assignment the formula shows the TCH assignment success rate for calls started in the cell: T asSUC = Equation 13 T CASSALL 0 Inc (AB + AW ) + Outg (AB + AW ) 3 100 [%] T ASSALL 0 Inc (AB + AW ) + Outg (AB + AW ) Assignment Success Rate for Over- and Underlaid Subcell Where 216/1553-HSC 103 12/16 Uen E | 2010-11-10 43 User Description, Radio Network Statistics 5.4.7 Inc Sum of all incoming handovers to a cell from all its neighbors. Outg Sum of all outgoing handovers from a cell to all its neighbors. AW Number of successful assignments to worse cell, counter HOSUCWCL. AB Number of successful assignments to better cell, counter HOSUCBCL. Drops on SDCCH Object types concerned are CLSDCCH, CLSDCCHO and CELLCCHDR. 44 CNDROP The total number of dropped SDCCH channels in a cell. CNRELCONG Number of released connection on SDCCH due to TCH— and transcoder congestion in underlaid and overlaid subcell. The subset for overlaid subcells is CNRELCONGSUB. The two counters are located in CLSDCCH and CLSDCCHO respectively. CNDROP is stepped at the same time. CDISTA Dropped SDCCH connection at excessive Timing Advance (TA). CDISSS Dropped SDCCH connection at low signal strength on down— or uplink in underlaid subcell i.e. below LOWSSDL and/or LOWSSUL. There is also a counter for overlaid subcell, CDISSSSUB. CDISQA Dropped SDCCH connection at bad quality down— or uplink per cell in underlaid subcell i.e. worse than BADQDL and/or BADQUL. There is also a counter for overlaid subcell, CDISQASUB. CLUNDROP The total number of dropped SDCCH channels during location area update in a cell. The counter CLUNDROP is incremented for abnormal terminations that occur during location area update. CLUDISTA Dropped SDCCH connection during location area update at excessive Timing Advance (TA). CLUDISTA works as CDISTA, but is only incremented for drops during location area update. CLUDISSS Dropped SDCCH connection during location area update at low signal strength on down— or uplink in underlaid subcell i.e. below LOWSSDL and/or LOWSSUL. There is also a counter for overlaid subcell, 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring CLUDSSSUB. CLUDISSS and CLUDISSSSUB works as CDISSS and CDISSSSUB respectively, but are only incremented for drops during location area update. Dropped SDCCH connection during location area update at bad quality down— or uplink per cell in underlaid subcell i.e. worse than BADQDL and/or BADQUL. There is also a counter for overlaid subcell, CLUDISQASUB. CLUDISQA and CLUDISQASUB works as CDISQA and CDISQASUB respectively, but are only incremented for drops during location area update. CLUDISQA The different drop reasons are ranked in the order excessive TA, low signal strength, bad quality or sudden loss of connection. This means that if connection suffers from excessive TA and low signal strength and drops, the drop reason will be registered as excessive TA. The urgency condition bad quality is triggered by a high bit error rate on up- or downlink. Note that there are separate counters which only step for the above reasons during location area updates. The formula for drop on SDCCH, drop due to TCH congestion excluded, is: Sdr = CNDROP 0 CNRELCONG 3 100 [%] CMSEST AB Equation 14 5.4.8 Drop Rate on SDCCH, Drops Due to TCH Congestion Excluded Congestion A low congestion rate is very important for the general performance improvement. A lot of revenue gain is to be made if the congestion is kept as low as possible. The object types concerned are CLSDCCH, CLSDCCHO, CELTCHF, CELTCHH. CCONGS Congestion counter for underlaid subcell. Stepped each time an allocation attempt fails due to SDCCH congestion. Also available for overlaid subcells, CCONGSSUB. CTCONGS Congestion time counter for underlaid subcell. The counter is stepped each second all available SDCCH channels are busy. Also available for overlaid subcells, CTCONSUB. CSCSTCONG Congestion time counter for signalling connection setup for procedures requiring a TCH. Starts incrementing when a signalling connection setup attempt for a procedure requiring a TCH fails and stops incrementing when there is a successful signalling connection setup of any kind on a SDCCH or a TCH. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 45 User Description, Radio Network Statistics CSCSOPTCONG Congestion time counter for signalling connection setup for procedures that can be completed on a SDCCH. Starts incrementing when a signalling connection setup attempt for a procedure that can be completed on an SDCCH fails and stops incrementing when there is a successful signalling connection setup of any kind on a SDCCH. CNRELCONG Number of released connections on SDCCH due to TCH— or Transcoder (TRA) congestion in both underlaid and overlaid subcell. The subset for overlaid subcells is CNRELCONGSUB. CNDROP is stepped at the same time. TFNRELCONG Number of released TCH signalling connections due to transcoder resource congestion during immediate assignment on TCH. The corresponding counter for half-rate is THNRELCONG. These counters are also available for overlaid subcell as TFNRELCONGSUB and THNRELCONGSUB. TFNDROP is stepped at the same time. TFCONGSAS Number of failed channel allocation attempts at assignment or immediate assignment in underlaid subcell. The counter is also available for half-rate and for overlaid subcells, e.g. THCONGSASSUB. TFCONGSHO Number of congestion at incoming handover in underlaid subcell. The counter is also available for half-rate and for overlaid subcells, e.g. THCONGSHOSUB. TFTCONGS Soft congestion time counter for underlaid subcell. The counter starts to increment when a channel is requested but no idle channels are available. The corresponding half-rate counter for overlaid subcells is named THTCONSUB. In the case of GPRS no consideration is made as to whether on-demand PDCHs exist in the cell or not i.e. both on-demand and fixed PDCHs are regarded as busy. TFTHARDCONGS Hard congestion time counter for underlaid subcell. The counter starts to increment only when it has not been possible to allocate a channel with the help of any type of preemption. The corresponding counter for overlaid subcells is named TFTHARDCONSUB. The corresponding counters for halfrate are called THTHARDCONGS and THTHARDCONSUB In the case of GPRS no consideration is made as to whether on-demand PDCHs exist in the cell, simply whether the preemption has failed or not. CCALLS and PERLEN are also used in the formulas below. 46 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring The different counters for assignment attempts at congestion, CCONGS, TFCONGSAS etc., are usually stepped several times during a call setup, thus showing very high values although the time congestion, see below, is still low. The formula below should therefore be used with that in mind: Scong = CCONGS 3 100 [%] CCALLS Equation 15 SDCCH Congestion Ratio in Underlaid Subcell The time congestion for SDCCH in percentage of the measured period in underlaid subcell can be written as follows: Scongt = CT CONGS 3 100 [%] P ERLEN 3 60 Equation 16 Full-Rate SDCCH Time Congestion in Underlaid Subcell When looking at congestion for signalling connection setup, the following must be kept in mind: • When trying to set-up a signalling connection the mobile will retry several times to setup up a connection in case of congestion. Looking at a success rate on an attempt basis will thus not show a subscriber perceived congestion. • If allowing Immediate Assignment on TCH, signalling connection setup for procedures that require a TCH might be successful even in case of complete SDCCH congestion in the cell. • To see the SDCCH congestion on cell level it is not possible just to add the SDCCH time congestion in the overlaid and underlaid subcells, as there might be available channels in one if the subcells even if the other is congested. How to determine the congestion on cell level depends on the channel allocation profile, normally the underlaid subcell is the last to be congested. The counter CSCSTCONG and CSCSOPTCONG give a picture of the signalling congestion setup congestion on cell level separately for procedures requiring a TCH and other procedures, e.g. SMS and location area update, that can be completed on an SDCCH. On cell level it is not possible to get a consistent definition of time congestion that is connected to availability of resources (for example MSs outside the overlaid coverage area may suffer congestion even if there are free channels in the overlaid subcell), instead these counters consider successful and unsuccessful signalling connection setups. The counter CSCSTCONG starts incrementing when a signalling connection setup attempt for a procedure requiring a TCH fails and stops incrementing when there is a successful signalling connection setup of any kind on a SDCCH or a TCH. The counter CSCSOPTCONG on the other hand starts incrementing when a signalling connection setup attempt for a procedure that can be completed on an SDCCH fails and stops incrementing when there is a successful signalling connection setup of any kind on a SDCCH. As the counters consider successful establishments rather than resource availability 216/1553-HSC 103 12/16 Uen E | 2010-11-10 47 User Description, Radio Network Statistics the actual congestion time might be slightly exaggerated in cells with low SDCCH traffic and capacity. It should be noted that BSS cannot in all cases determine if a connection is for a procedure requiring a TCH or signalling only, if not known it is assumed that it is for a procedure requiring a TCH. The formula below shows the congestion time for procedures that require a TCH SIGcongt = CSCST CONG 3 100 [%] P ERLEN 3 60 Equation 17 Signalling Connection Setup Time Congestion for Procedures that Require a TCH The counters TFCONGSAS, THCONGSAS etc. might be stepped several times during an assignment attempt. Instead, a more accurate measure of the number of call attempts failing due to TCH congestion is the number of signalling channel drops due to lack of radio resources, i.e. TCH congestion. The counter to use is CNRELCONG situated in the object type CLSDCCH and the TFNRELCONG counters. The expression below is a good measure of the subscriber perceived Grade of Service (GoS) in the cell. The formula compares the failed TCH assignment attempts due to congestion with the total number of TCH assignment attempts. Successful attempts are counted in the target cell and failed attempts are counted in the serving cell. By compensating for handover during assignment the formula shows the congestion for calls started in the cell TFrelC = TFNRELCONG + TFNRELCONGSUB THrelC = THNRELCONG + THNRELCONGSUB T cong = CNRELCONG + T F relC + T HrelC 3 100 [%] T ASSALL 0 Inc (AB + AW ) + Outg (AB + AW ) Equation 18 Subscriber Perceived TCH Congestion. The expressions above can be described as: T_CONG Total number of dropped calls due to TCH congestion divided by the total number of TCH assignments. TFrelC Total number of dropped TCH connections due to transcoder resource congestion at immediate assignment on TCH for full-rate in both underlaid and overlaid subcell. THrelC Total number of dropped TCH connections due to transcoder resource congestion at immediate assignment on TCH for half-rate in both underlaid and overlaid subcell. The TCH time congestion is also a useful measure. The time congestion for TCH full-rate in percentage of the measured period in underlaid subcell can be written as follows: 48 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring T congt = T F T CONGS 3 100 [%] P ERLEN 3 60 Equation 19 5.4.9 Full-Rate TCH Time Congestion in Underlaid Subcell RF Output Power Supervision Measurements per BSC The counters described in this section belong to the object type BSCRFSUP and Measurements are done per BSC. The main purpose of these counters is to monitor the RF performance and quality and is associated with RF performance alarms. ALRFPERFACC The accumulated number of RADIO X-CEIVER ADMINISTRATION MANAGED OBJECT FAULT alarms with alarm slogan RF PERFORMANCE and RADIO X-CEIVER ADMINISTRATION TRANSCEIVER GROUP FAULT alarms with alarm slogan RF PERFORMANCE. The number of currently active alarms is scanned every five minutes. ALNOTRAFACC The accumulated number of CELL RF OUTPUT POWER SUPERVISION alarms with the reason NO TRAFFIC. The number of currently active alarms is scanned every five minutes. ALLOWDLQUALACC The accumulated number of CELL RF OUTPUT POWER SUPERVISION alarms with the reason LOW DL QUALITY. The number of currently active alarms is scanned every five minutes. ALNSCAN 5.5 Retainability 5.5.1 General The counter is incremented by one every five minutes when the number of currently active alarms is scanned in order to update the counters ALRFPERFACC, ALNOTRAFACC and ALLOWDLQUALACC. The retainability area within the radio network covers the performance regarding dropped calls, lost handovers and disconnections during abnormal circumstances etc. The following BSC exchange properties are affecting counters for dropped calls and handover: HIGHFERDLFR 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Threshold value for FER downlink for fullrate. Filtered FER measurements on the downlink for fullrate are compared to HIGHFERUL when evaluating urgency 49 User Description, Radio Network Statistics conditions. The evaluated condition is used for statistical counter incrementation only. There are separate BSC exchange properties for uplink, downlink and per codec halfrate, fullrate, enhanced fullrate, AMR halfrate and AMR fullrate. For example the corresponding parameter for uplink and AMR halfrate is HIGHFERULAHR. Note that evaluation of the FER threshold requires the feature Enhanced Measurement Reporting (EMR). Value range: 0-96 FER units. Default value: 4 FER Units. 5.5.2 BADQDL Threshold value for Bad Quality downlink based on RXQUAL. Filtered quality measurements on the downlink are compared to BADQx when evaluating urgency conditions. The evaluated condition is used for statistical counter incrementation only. The corresponding parameter for uplink is BADQUL. Value range: 0-100dtqu. Default value: 55dtqu. LOWSSDL Threshold values for attenuation of Signal Strength downlink. Filtered downlink signal strength values are compared with LOWSSx when analyzing urgency conditions. The evaluated condition is used for statistical counter incrementation only. The corresponding parameter for uplink is LOWSSULValue range: -47-(-110)dBm. Default value: -104dBm. Dropped Calls Object types concerned are CELTCHF, CELTCHH, CLTCHDRF and CLTCHDRH. TFNDROP The total number of dropped full-rate TCH in underlaid subcell. The counter is also available for half-rate and for overlaid subcells, e.g. THNDROPSUB. TFNCEDROP The total number of dropped full rate TCH connections in underlaid subcell that occur when a subscriber to subscriber connection has already been established. The counter is incremented when a connection is dropped after any of the three messages 44.018 ASSIGNMENT COMPLETE, 44.018 HANDOVER COMPLETE, 44.018 CHANNEL MODE MODIFY ACKNOWLEDGE and before one of the DTAP messages 24.008 RELEASE or 24.008 DISCONNECT is received by the BSC. For inter BSC handovers and inter system handovers, the target BSC assumes that the call connection is already established, and the counter is incremented in the target BSC in case of dropped connection. The counter is also available for half-rate and for overlaid subcells, e.g. THNCEDROPSUB. 50 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring TFDISTA Total number of dropped full-rate TCH connections at excessive TA. Also available for half-rate, e.g. THDISTA. TFDISSSUL Total number of dropped full-rate TCH connection at low signal strength on uplink in underlaid subcell i.e. below LOWSSUL. Different combinations for overlaid subcell, up/down and both-way link and half-rate, e.g. THDISSSBLSUB is the signal strength drop counter for half-rate, both links in overlaid subcell. If both links have low signal strength, only the both link counters are stepped. TFDISFERUL Total number of dropped full-rate TCH connections at high FER on uplink in underlaid subcell i.e. worse than (above) HIGHFERULFR. Different combinations for overlaid subcell, up/down and both-way link and codec, e.g. THDISFERBLSUB is the bad quality drop counter for half-rate, both links in overlaid subcell. If both links have bad quality, only the both link counters are stepped. TFDISQAUL Total number of dropped TCH connection due to bad quality based on RXQUAL on uplink in underlaid subcell i.e. worse than (above) BADQUL. Different combinations for overlaid subcell, up/down and both ways link and half-rate, e.g. THDISQABLSUB is the bad quality drop counter for half-rate, both links in overlaid subcell. If both links have bad quality, only the both link counters are stepped. TFSUDLOS Sudden loss of connection in underlaid subcell. Sudden loss apply when the locating algorithm indicates missing measurement results, but none of the urgency conditions mentioned above (that is excessive TA, low signal strength, high FER or bad quality) apply. The counter is also available for half-rate and for overlaid subcells, e.g. THSUDLOSSUB. The different drop reasons are ranked in the order excessive TA, low signal strength, high FER, bad quality or sudden loss of connection. This means that if connection suffers from excessive TA and low signal strength and drops, the drop reason will be registered as excessive TA. The number of drops due to other reasons is obtained by subtracting the drops with known reasons from the total number of drops. This applies to both SDCCH and TCH. To obtain a subscriber perceived drop rate the number of drops should be compared to the number of calls terminated in the cell, but when calculating this, the net sum of incoming calls via all relations have to be included. The following list shows the components included: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 51 User Description, Radio Network Statistics Ncalls Number of calls terminated in a cell. Icalls Number of initiated calls in a cell, e.g. the sum of the four “CASSALL” counters for TCH or CMSESTAB for SDCCH. Inc Sum of all incoming handovers to a cell from all its neighbors. Outg Sum of all outgoing handovers from a cell to all its neighbors. AW Number of successful assignments to worse cell, counter HOSUCWCL. AB Number of successful assignments to better cell, counter HOSUCBCL. The total number of terminated calls in a cell is then expressed as: Ncalls = Icalls + Inc (AB + AW ) 0 Outg (AB + AW ) Equation 20 Net Sum of Calls Terminated in Cell As an abbreviation in the following expressions the following sum is used for the total amount of TCH drops (the SDCCH drop counter is CNDROP): TNdrop = TFNDROP + TFNDROPSUB + THNDROP + THNDROPSUB Equation 21 Total Number of Drops on TCH The formula for subscriber perceived drop on TCH can then be written as: TdrS = TNdrop Ncalls 3 100 [%] Equation 22 Subscriber Perceived Drop Rate on TCH Please, note that if there are many incoming handovers from a 3G network, the drop formula will be skewed to worse values if a call initiated in the 3G network drop in the GSM network. The reason is that while the drop will be registered in the GSM network i.e. increasing the nominator in Equation 22 the denominator will not be increased as the call started in the 3G network. If there is a large number of incomming handovers from a 3G network it is recommended to use the following formula in order to have a drop rate which is not affected by incoming 3G handovers: 100 3 TxNDROP TCHdropNo3Ginitiated = (DISNORM + TxNDROP ) [%] Equation 23 52 Subscriber Perceived Drop Rate on TCH, not affected by incoming handovers from 3G. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring To obtain the ratios for the different reasons the following expression can be used. It shows the ratio of drops due to low signal strength on either downlink, uplink or both links on TCH compared to the total number of TCH drops. As a help expression the drops due to low signal strength on uplink, downlink and both links are grouped together for each rate and subcell as shown below. T F disss = T F DISSSU L + T F DISSDL + T F DISSSBL Equation 24 Total Number of TCH Drops Due to Low Signal Strength in Underlaid Subcell, Full-Rate Channel With use of these expressions the ratio of TCH drops due to low signal strength is written as follows. Please note that the drop terms below are sums of counters as shown above. T drSS = T Hdissssub + T Hdisss + T F dissssub + T F disss 3 100 [%] T Ndrop Equation 25 Ratio of TCH Drops Due to Low Signal Strength, All Rates, Whole Cell The same method can be used to calculate the following drop reasons for both full-rate and half-rate calls: T_DR_BQ The rate of TCH drops at bad quality on either uplink, downlink or both for the whole cell. T_DR_FER The rate of TCH drops at high FER on either uplink, downlink or both for the whole cell. T_DR_TA The rate of TCH drops due to excessive Timing Advance for the whole cell. T_DR_SUD The rate of TCH drops due to sudden loss of the connection for the whole cell. T_DR_OTH The rate of TCH drops due to other reasons than the above known reasons. A cell with a very high rate of TCH drops due to other reasons should be investigated in terms of consistent parameter settings (both cell and managed objects), BTS alarms, software status, antenna faults, link problems and transcoder problems. A useful value for comparing performance is to calculate the number of call minutes per drop, e.g. the average time period between full-rate TCH drops in minutes per call. This measure takes the traffic level into account. The following formula applies to TCH: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 53 User Description, Radio Network Statistics T F drCALL = Equation 26 P ERLEN 3 T F T RALACC (T F NDROP + T F NDROPSUB ) 3 T F NSCAN [min] Average Time Period between Full-Rate TCH Drops in Minutes per Call The expression above can be altered to include for instance drop reasons instead. To get a better picture of the subscriber impact due to dropped calls, the counters that are only stepped for dropped calls when a call connection is established can be used (e.g. the counter TFNCEDROP for full rate underlaid subcell). It is assumed that the subscriber perceived disturbance is greater if the call drops when the call connection has been established. The ratio of calls for full rate connections that are dropped when a call connection is established of all TCH drops can be calculated as: CEdrCALL = Equation 27 5.5.3 T F NCEDROP + T F NCEDROP SUB 3 100 [%] T F NDROP + T F NDROP SUB Percentage Full Rate TCH Drops when a Call Connection Is Established of All TCH Drops AMR and Dropped Calls Counters are available for the number of dropped calls that occurred on AMR codecs and the reason for these dropped calls. The object type CLTCHDRAF contains 21 counters for AMR full rate, the object type CLTCHDRAH contains 21 counters for AMR half rate and the object type CLTCHDRAW contains 21 counters for AMR wideband. Separate counters are provided per reason (timing advance, low signal strength, high FER, bad quality and sudden loss) and also per underlaid and overlaid subcell in a similar manner as the more general counters. Some examples of the naming convention are given below: 54 TFDISTAA Total number of dropped AMR full-rate TCH connections at excessive TA. Also available for half-rate, e.g. THDISTAA . TFDISSULA Total number of dropped AMR full-rate TCH connections due to low signal strength on uplink in underlaid subcell i.e. below LOWSSUL. Different combinations for overlaid subcell, up/down/both links and half-rate, e.g. THDISSBLSUBA is the signal strength drop counter for AMR half-rate, both links in overlaid subcell. If both links have low signal strength, only the both link counters are stepped. TFDISFERULA Total number of dropped AMR full rate TCH connections at high FER on uplink in underlaid subcell. Different combinations for overlaid subcell, up/down and both-way link and codec, e.g. THDISFERBLSUBA is 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring the bad quality drop counter for AMR half-rate, both links in overlaid subcell. If both links have bad quality, only the both link counters are stepped. TFDISQAULA Total number of dropped AMR full-rate TCH connections at bad quality on uplink in underlaid subcell. Different combinations for overlaid subcell, up/down/both links and half-rate, e.g. THDISQABLSUBA is the bad quality drop counter for AMR half-rate, both links in overlaid subcell. If both links have bad quality, only the both link counters are stepped. TFSUDLOSA Sudden loss of AMR full-rate connection in underlaid subcell. Sudden loss apply when the locating algorithm indicates missing measurement results, but none of the urgency conditions mentioned above (that is excessive TA, low signal strength, high FER or bad quality) apply. The counter is also available for AMR half-rate and for overlaid subcells, e.g. THSUDLOSSUBA. The general counters for dropped calls on all full-rate codecs are still stepped when one of these counters specific to AMR codecs is stepped. For example if an AMR full-rate connection is dropped because of low signal strength on the downlink in the overlaid subcell then TFNDROP, TFDISSSDLSUB and TFDISSDLSUBA are all stepped. 5.5.4 Enhanced AMR Coverage Counters to monitor the feature Enhanced AMR Coverage is available in the object type CLTCHEAS. These counters act for terminals having repeated SACCH capability. Repeated SACCH capability enhance the terminals ability to decode signalling under bad radio conditions, see Ref. Reference [40] for details. EASULACTMREP The counter is stepped for each Measurement Report that is received while the terminal is in repeated SACCH mode on the uplink. EASULCAPMREP The counters is stepped for each Measurement Report that is received from an MS capable of repeated SACCH, while the feature Enhanced AMR Coverage is activated in the BSC. EASDLACTSBL The counter is stepped for each DL SACCH block received by the MS while in repeated SACCH mode on the downlink. EASDLCAPSBL The counters is stepped for each DL SACCH block received by an MS capable of repeated SACCH, while the feature Enhanced AMR Coverage is activated in the BSC. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 55 User Description, Radio Network Statistics Using the above counters it is possible to calculate the fraction of time repeated SACCH is used on the Uplink and Downlink, respectively. EASULACTMREP 3 100 [%] EACul = EASULCAPMREP Equation 28 The fraction of the in repeated SACCH mode on the uplink. EASDLACTMREP 3 100 [%] EACdl = EASDLCAPMREP Equation 29 5.5.5 The fraction of the in repeated SACCH mode on the uplink. Disconnection This section concerns normal disconnections of speech TCHs. There are counters to get information about the circumstances when the disconnection was made, thus getting indicators about subscriber perceived quality although no call drops are registered. The object type for disconnections is CELEVENTD. DISNORM Normal disconnection. When DISNORM is stepped during urgency state also the following counters are stepped: DISETA Normal disconnection at excessive timing advance. DISBSS Normal disconnection at low signal strength. DISBQA Normal disconnection at bad quality. DISRET3G Disconnection with request to immediately connect to UTRAN network. The counters are stated in order of urgency status, e.g. if a call suffers from both bad signal strength and too high timing advance the disconnection is counted by DISETA. For instance, to get the ratio of disconnected calls during bad quality the formula below can be used. DISBQA 3 100 [%] TERMbq = DISNORM Equation 30 5.5.6 Ratio of Subscriber Initiated Disconnections at Bad Quality Handover The counters in this section belongs to the object types NCELLREL, NICELHO and NICELASS. If Ericsson 3 locating algorithm is used, the object type NICELHOEX have to be considered. NICELHOEX can also be used to measure high handover rate. There are corresponding counters for handovers 56 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring to external neighbour cells; NECELLREL, NECELHO, NECELSASS and NECELHOEX respectively, which contain the same set of counters. The most important counters are: HOVERCNT Number of Handover Commands sent to the MS. HOVERSUC Number of successful handover to the neighboring cell. HORTTOCH Number of handover attempts where the MS returns to the old channel or has been ordered by the network and succeeded in getting back to the old channel. HODUPFT Number of successful handovers back to old cell within 10 seconds. HOTOKCL Handover attempt made to better K-cell (only for the Ericsson 1 locating algorithm). The corresponding for better L-cell is called HOTOLCL. HOTOHCS Handover attempt due to HCS. HODWNQA Number of handover attempts due to bad downlink quality. There is one HO counter for bad uplink quality called HOUPLQAand one for excessive timing advance called HOEXCTA. HOASBCL Number of assignment attempts to better cell. The corresponding counter for assignment to worse cell is called HOASWCL. HOSUCBCL Number of successful assignment attempts to better cell. The corresponding counter for assignment to worse cell is called HOSUCWCL. HOATTLSS Number of handover attempts when the serving cell is a low signal strength cell. The corresponding counter for attempts at high signal strength is called HOATTHSS. HOATTHR Number of handover attempts at high handover rate. The counter for successful handovers at high handover rate is HOSUCHR. Note, “attempt” for the counters above is before a channel has been allocated i.e. in the case of congestion the “attempt” will fail. A better way to express this would be to use the term “decision” and to use the term “attempt” for the actual attempt to perform e.g. a handover (when handover command is sent). The number of lost handovers is counted by subtracting HOVERSUC and HORTTOCH from HOVERCNT and the ratio of all handovers is given by: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 57 User Description, Radio Network Statistics HOV ERSUC 0 HORTTOCH 3 100 [%] Hlost = HOV ERCNT 0 HOV ERCNT Equation 31 Ratio of Handovers Lost of Total Number of Handover Commands To see the ratio on cell level, all cell relations have to be summarized. 5.6 Speech Quality 5.6.1 General From BSS R12 speech quality measures are only collected in the STS counters when a call connection is established, to make better correlation to the subscriber perceived speech quality. If a call connection has been established is detected by the DTAP message Connect Acknowledge and if the call connection has been terminated is determined by the DTAP messages Release or Disconnect (which ever comes first). For inter BSC handovers it is assumed that the call connection is established. This applies to SQI, FER and RXQUAL measurements in the object types CLRXQUAL, CELLSQI, CELLFERF, CELLFERH, CHGRP0H, CHGRP0F, CELLAFFER, CELLAHFER, CELLEFFER, CELFFER, CELLHFER, CELLSQIDL, CHGRP0SQI and CELLAWFER. More information about the FER and SQI measurements can be found in Reference [32]. 5.6.2 Speech Quality Supervision for Speech Version 1 and 2 Codecs The object type CELLSQI contains three counters that show how the speech quality indexes are distributed UL, according to subscriber perceived quality, as good, acceptable and bad for the underlaid subcell. These counters only step for Speech Version 1 (FR and HR) and Speech Version 2 (EFR) codecs. There are three matching counters for overlaid subcells. The object type CELLSQIDL contains the corresponding counters but for DL. The counters have the same name as the UL counters, but with the suffix DL. Note that SQI DL requires the feature Enhanced Measurement Reporting. 58 TSQIGOOD Accumulated number of SQI samples that represented good speech quality. The corresponding counter for overlaid subcell is TSQIGOODSUB TSQIACCPT Accumulated number of SQI samples that represented acceptable speech quality. The corresponding counter for overlaid subcell is TSQIACCPTSUB 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring Accumulated number of SQI samples that represented unsatisfactory speech quality. The corresponding counter for overlaid subcell is TSQIBADSUB TSQIBAD Shown below is the percentage of SQI samples in the range good out of the total number of SQI samples. The same measure can be calculated for acceptable and unsatisfactory samples. As a help expression, the total number of SQI samples in underlaid subcell is calculated first. SQItot = T SQIGOOD + T SQIACCP T + T SQIBAD Equation 32 SQIgood = Total Number of SQI Samples T SQIGOOD 3 100 [%] SQItot Equation 33 Percentage Good SQI Samples of Total Number of SQI Samples For further information about SQI, see Reference [32]. 5.6.3 Speech Quality Supervision for Speech Version 3 and 5 (AMR FR, AMR HR and AMR Wideband) The counters in the object type CELLSQI is used to monitor the speech quality UL, separately for AMR wideband, AMR full rate and AMR half rate and per underlaid/overlaid subcell. The object type CELLSQIDL contains the corresponding counters but for DL. The counters have the same name as the UL counters, but with the suffix DL. Note that SQI DL requires the feature Enhanced Measurement Reporting. TSQIGOODAW Accumulated number of SQI samples for AMR wideband that represented good speech quality. The corresponding counter for overlaid subcell is TSQIGOODSUBAW TSQIACCPTAW Accumulated number of SQI samples for AMR wideband that represented acceptable speech quality. The corresponding counter for overlaid subcell is TSQIACCPTSUBAW TSQIBADAW Accumulated number of SQI samples for AMR wideband that represented unsatisfactory speech quality. The corresponding counter for overlaid subcell is TSQIBADSUBAW TSQIGOODAF Accumulated number of SQI samples for AMR full rate that represented good speech quality. The corresponding counter for overlaid subcell is TSQIGOODSUBAF 216/1553-HSC 103 12/16 Uen E | 2010-11-10 59 User Description, Radio Network Statistics TSQIACCPTAF Accumulated number of SQI samples for AMR full rate that represented acceptable speech quality. The corresponding counter for overlaid subcell is TSQIACCPTSUBAF TSQIBADAF Accumulated number of SQI samples for AMR full rate that represented unsatisfactory speech quality. The corresponding counter for overlaid subcell is TSQIBADSUBAF TSQIGOODAH Accumulated number of SQI samples for AMR half rate that represented good speech quality. The corresponding counter for overlaid subcell is TSQIGOODSUBAH TSQIACCPTAH Accumulated number of SQI samples for AMR half rate that represented acceptable speech quality. The corresponding counter for overlaid subcell is TSQIACCPTSUBAH TSQIBADAH Accumulated number of SQI samples for AMR half rate that represented unsatisfactory speech quality. The corresponding counter for overlaid subcell is TSQIBADSUBAH It is suggested to construct similar formulas as in Section 5.6.2 on page 58 above. 5.6.4 Speech Codec Congestion In object type BSCSCCCL, there are counters on BSC level which give statistics about speech codec utilization and indicate potential quality problem caused by speech codec congestion due to the SCC capacity lock mechanism. There are two counters per optional speech codec,(i.e. AMR FR, AMR HR, AMR WB, EFR and HR) as listed below. 60 TCONGAFR Total time in seconds when no speech resource for AMR FR has been available for new traffic due to SCC capacity lock mechanism. TCONGAHR Total time in seconds when no speech resource for AMR HR has been available for new traffic due to SCC capacity lock mechanism. TCONGAWB Total time in seconds when no speech resource for AMR WB has been available for new traffic due to SCC capacity lock mechanism. TCONGEFR Total time in seconds when no speech resource for EFR has been available for new traffic due to SCC capacity lock mechanism. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring TCONGHR Total time in seconds when no speech resource for HR has been available for new traffic due to SCC capacity lock mechanism. TRAFAFR Accumulated traffic level (number of calls) using AMR FR speech codec. TRAFAHR Accumulated traffic level (number of calls) using AMR HR speech codec. TRAFAWB Accumulated traffic level (number of calls) using AMR WB speech codec. TRAFEFR Accumulated traffic level (number of calls) using EFR speech codec. TRAFHR Accumulated traffic level (number of calls) using HR speech codec. TRAFSCAN Number of accumulations of traffic level counters. In order to calculate the current traffic level on BSC level for a specific optional speech codec one can e.g use the formula in Equation 34which is showing the AMR FR traffic in Erlang on BSC level. The optional speech codec utilization on BSC level can be calculated by dividing the calculated traffic level (e.g. Equation 34) with the BSC capacity limit (c.f. AXE parameter, printout RACLP). T raffAMRF Rbsc = Equation 34 T RAF AF R [Erlang] T RAF SCAN AMR Full-Rate Traffic Level in a BSC In order to monitor the details of speech codec capacity with respect to the SCC capacity lock mechanism on cell level, the object types CLTCHFV2, CLTCHHV1, CLTCHFV3, CLTCHHV3 and CLTCHFV5 (with counters used for cell level measurements for All Speech Versions) have been updated with the following congestion counters: THV1TCONGSCC Total congestion time (in seconds) when no speech codec resource for HR has been available to setup new traffic due to the SCC capacity lock mechanism. TFV2TCONGSCC Total congestion time (in seconds) when no speech codec resource for EFR has been available to setup new traffic due to the SCC capacity lock mechanism. TFV3TCONGSCC Total congestion time (in seconds) when no speech codec resource for AMR FR has been available to setup new traffic due to the SCC capacity lock mechanism. THV3TCONGSCC Total congestion time (in seconds) when no speech codec resource for AMR HR has been available to setup new traffic due to the SCC capacity lock mechanism. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 61 User Description, Radio Network Statistics TFV5TCONGSCC 5.6.5 Total congestion time (in seconds) when no speech codec resource for AMR WB has been available to setup new traffic due to the SCC capacity lock mechanism. Speech Quality Supervision with Frame Erasure Rate (FER) Counters, UL The object types CELLFERF and CELLFERH contain counters to allow the frame erasure rate, as measured by the BTS on the uplink, to be calculated per cell. Note that the counters also allow the frame erasure rate for Speech Version 1 and Speech Version 2 to be calculated. 62 TFV3FERCM1 Number of frames erased by the BTS for full rate AMR codec mode 1. TFV3FERCM2 is the corresponding counter for AMR codec mode 2. TFV3FERCM3 is the corresponding counter for AMR codec mode 3. TFV3FERCM4 is the corresponding counter for AMR codec mode 4. TFV3TFCM1 Total number of frames transmitted by the MS for full rate AMR codec mode 1. TFV3TFCM2 is the corresponding counter for AMR codec mode 2. TFV3TFCM3 is the corresponding counter for AMR codec mode 3. TFV3TFCM4 is the corresponding counter for AMR codec mode 4. TFV5FERCM1 Number of frames erased by the BTS for full rate AMR Wideband codec mode 1. TFV5FERCM2 is the corresponding counter for AMR Wideband codec mode 2. TFV5FERCM3 is the corresponding counter for AMR Wideband codec mode 3. TFV5TFCM1 Total number of frames transmitted by the MS for AMR wideband codec mode 1. TFV5TFCM2 is the corresponding counter for AMR wideband codec mode 2. TFV5TFCM3 is the corresponding counter for AMR wideband codec mode 3. TFV1FER Number of frames erased by the BTS for full rate Speech Version 1. TFV2FER is the corresponding counter for full rate Speech Version 2 (EFR). TFV1FERTF Total number of frames transmitted by the MS for full rate full rate Speech Version 1. TFV2FERTF is the corresponding counter for full rate Speech Version 2 (EFR). THV3FERCM1 Number of frames erased by the BTS for half rate AMR codec mode 1. THV3FERCM2 is the corresponding counter for AMR codec mode 2. THV3FERCM3 is the corresponding counter for AMR codec mode 3. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring THV3FERCM4 is the corresponding counter for AMR codec mode 4. THV3TFCM1 Total number of frames transmitted by the MS for half rate AMR codec mode 1. THV3TFCM2 is the corresponding counter for AMR codec mode 2. THV3TFCM3 is the corresponding counter for AMR codec mode 3. THV3TFCM4 is the corresponding counter for AMR codec mode 4. THV1FER Number of frames erased by the BTS for half rate Speech Version 1. THV1FERTF Total number of frames transmitted by the MS for half rate full rate Speech Version 1. The FER is calculated by dividing the number of frames erased by the total number of frames received. If the FER for a certain codec mode is too high then the C/I threshold for the change of codec mode may need to be adjusted to ensure optimal speech quality. 5.6.6 Detailed FER measurements (available using EBA) Detailed FER calculation Distribution Monitors are introduced in EBA in 07B. The Detailed FER input data (UL/DL) to the monitors are calculated in the BSC and requires the optional features Speech Quality Supervision, Enhanced Measurement Reporting (EMR) and EMR capable terminals. The Detailed FER values are measured by the BSC over a user definable interval N (set by BSC command RLSQC using parameter WINSIZE), having the value range 2-40 SACCH periods with default value 4. Furthermore, a Sliding Window mechanism is used to measure the new Detailed FER and Detailed RXQUAL values, meaning that after WINSIZE number of SACCH periods with allowed FER values, there will be a Detailed FER measure reported each SACCH period. Note that only SACCH periods with allowed data are contributing to the measurements. This means that the Detailed FER measurements are calculated over WINSIZE number of SACCH periods with allowed values. The Detailed FER calculation can be filtered in EBA on e.g. Last Codec Mode used by the terminal in the measurement interval. The Detailed FER values calculated in the BSC are integer values in the range 0-1000 representing the value range 0.0-100.0 %, with 0.1% resolution. The Detailed FER values are converted to percentage values in EBA and shown in the ‘Detailed FER Distribution Monitor’. SACCH periods where the terminal is in DTX mode are not contributing to the Detailed FER calculation, while a measurement report that is lost is included in the calculation using the assumption that the loss is due to bad quality i.e. NBR_RCVD_BLOCKS=0. Note that the Detailed FER values are not affecting any ordinary FER measurements and is only used as input to the new EBA Detailed FER monitor. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 63 User Description, Radio Network Statistics This monitor treats all codec types (HR, FR, EFR and AMR) and also all codec modes for applicable codec types. 5.6.7 Detailed RXQUAL Measurements (Available using EBA) Detailed RXQUAL measurements Distribution Monitors are introduced in EBA in 07B. The Detailed RXQUAL input data ( UL/DL) to the monitors requires the optional features Speech Quality Supervision, Enhanced Measurement Reporting (EMR) and EMR capable terminals. The Detailed RXQUAL values are measured by the BSC over a user definable interval N (set by BSC command RLSQC using parameter WINSIZE), having the value range 2-40 SACCH periods with default value 4. Furthermore, a Sliding Window mechanism is used to measure the Detailed RXQUAL values, meaning that after WINSIZE number of SACCH periods there will be a Detailed RXQUAL measure reported each SACCH period. The Detailed RXQUAL measurements can be filtered in EBA on e.g. Last Codec Mode used by the terminal in the measurement interval. The Detailed RXQUAL values measured are based on MEAN_BEP reported by BTS (UL) and MS (DL) reported to the BSC. In the BSC the reported MEAN_BEP values are mapped to dtqu units, which are integer values in the range 0-76. This mapping corresponds to having decimal granularity of the traditional RXQUAL values, please see Table 10. The Detailed RXQUAL values are shown in the EBA ‘Detailed RXQUAL Distribution Monitor’. Note that the Detailed RXQUAL values are not affecting any ordinary RXQUAL measurements but is only used as input to the new EBA Detailed RXQUAL monitor. This monitor treat all codec types (HR, FR, EFR and AMR) and also all codec modes for applicable codec types. Note that since Detailed RxQual is based on MEAN_BEP, which is based on different measurements on biterrors than RXQUAL, there will not be a 10:1 relation, not even between the average Detailed RxQual and average RxQual. The mapping between MEAN_BEP, RXQUAL and Detailed RxQual is shown in Table 10. Table 10 Mapping of MEAN_BEP and dtqu (RxQual indicated as reference) MEAN_BEP RXQUAL Detailed RXQUAL (dtqu) MEAN_BEP RXQUAL Detailed RXQUAL (dtqu) 0 7 76 12 4 37 1 7 73 13 3 33 2 7 70 14 3 30 3 7 66 15 3 27 4 6 63 16 2 23 5 6 60 17 2 20 64 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring Table 10 Mapping of MEAN_BEP and dtqu (RxQual indicated as reference) 6 6 56 18 2 17 7 5 53 19 1 13 8 5 50 20 1 10 9 5 46 21 1 7 10 4 43 22 0 3 11 4 40 23-31 0 0 5.6.8 Frame Erasure Rate (FER) Distribution Counters, UL and DL There are counters that allow the distribution of FER occurrences to be plotted separately per codec type. The counters are divided in five different intervals (bins), the threshold for each bin can be set separately with parameters. There are counters separate for • Uplink and downlink • Underlaid and Overlaid subcell (if no subcell structure is used the Underlaid counter shows the whole cell) • Codec type (AMR Wideband, AMR FR, AMR HR, EFR, FR and HR • Separated in five different bins (intervals) The counters are located in the object types CELLAWFER for AMR wideband, CELLAFFER for AMR FR, CELLAHFER for AMR HR, CELLEFFER for EFR, CELLFFER for FR and CELLHFER for HR. The table below shows an example of the counters in object type CELLFFER for FR (Speech Version 1), SUB denotes the counter for Overlaid subcell. Table 11 FER Distribution Counters in Object Type CELLFFER for FR (Speech Version 1) BIN1 BIN2 BIN3 BIN4 BIN5 UL TF1ULFER TF2ULFE R TF3ULFE R TF4ULFER TF5ULFER UL/ TF1UL- TF2UL- TF3UL- TF4UL- TF5UL- SUB SUBFER SUBFER SUBFER SUBFER SUBFER DL TF1DLFER TF2DLFE R TF3DLFE R TF4DLFER TF5DLFER DL/ TF1DL- TF2DL- TF3DL- TF4DL- TF5DL- SUB SUBFER SUBFER SUBFER SUBFER SUBFER 216/1553-HSC 103 12/16 Uen E | 2010-11-10 65 User Description, Radio Network Statistics Counters in the other object types are constructed the same way, for example the counter name for AMR HR, Overlaid subcell, DL and bin 1 in object type CELLAHFER is TAH1DLSUBFER. More information can be found in Reference [32]. 5.6.9 Speech Quality Supervision with RXQUAL Counters, UL and DL The counters described below makes it possible to monitor the distribution of downlink and uplink RXQUAL values per cell using STS counters. The distribution of the RXQUAL values is not directly related to the speech quality. For example a network using tight frequency reuse with synthesizer hopping will have a higher number of RXQUAL=7 samples than a traditional 4/12 network with baseband hopping. However the speech quality for the users may actually be better in the tight frequency reuse network. The RXQUAL distribution is available for both the DL and UL though and is therefore still interesting to compare cells within the same network which use the same frequency planning method. It cannot be used to compare the speech quality between different networks or different areas in the same network that use different frequency planning methods. A more detailed investigation can then be performed using the MRR tool of RNO for different channel groups and speech codecs. Only RXQUAL values from measurement results for TCH connections are included in the counters (SDCCH excluded). The decision on whether to use the RXQUAL_FULL value or RXQUAL_SUB value in the measurement result to increment the counters is taken using the same method as used by the MRR tool. Object type: CLRXQUAL. Title: Counters for monitoring the distribution of downlink and uplink RXQUAL values, 16 counters per cell. 66 QUAL00DL Number of quality 0 reported on downlink. QUAL10DL Number of quality 1 reported on downlink. QUAL20DL Number of quality 2 reported on downlink. QUAL30DL Number of quality 3 reported on downlink. QUAL40DL Number of quality 4 reported on downlink. QUAL50DL Number of quality 5 reported on downlink. QUAL60DL Number of quality 6 reported on downlink. QUAL70DL Number of quality 7 reported on downlink. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring QUAL00UL Number of quality 0 reported on uplink. QUAL10UL Number of quality 1 reported on uplink. QUAL20UL Number of quality 2 reported on uplink. QUAL30UL Number of quality 3 reported on uplink. QUAL40UL Number of quality 4 reported on uplink. QUAL50UL Number of quality 5 reported on uplink. QUAL60UL Number of quality 6 reported on uplink. QUAL70UL Number of quality 7 reported on uplink. 5.7 Performance Measurement of Specific Radio Network Features 5.7.1 General For monitoring and tuning of radio network features there are several different STS counters implemented. In this chapter, STS counters and user formulas related to some features are outlined. In general, when tuning radio network features, all the performance measures described in Section 5 on page 35 should be monitored, but sometimes there is a need for focusing on specific areas. Therefore some of the counters are defined also in this chapter. For information about the different radio network features outlined in this chapter, see the User Descriptions and Engineering Guidelines for the concerned feature. 5.7.2 Intra-Cell Handover The object type CELEVENTI consists of counters related to Intra-cell Handover (IHO). It is possible to monitor the percentage of successful IHOs, IHOs due to bad quality on uplink, downlink and both links. Due to the feature Tight BCCH Frequency Reuse there are also counters to monitor the IHOs out from the BCCH channel group. HOINUQA Number of intra cell handover attempts (decisions) at bad uplink quality. The corresponding counter for the downlink is HOINDQAand for both links is HOINBQA. Only HOINBQA is stepped at bad quality on both links. HOINSUC Number of successful intra cell handovers. HOINBOCH Number of unsuccessful intra cell handover attempts where the MS returns to the old channel or has been 216/1553-HSC 103 12/16 Uen E | 2010-11-10 67 User Description, Radio Network Statistics ordered by the network and succeeded in getting back to the old channel. BCDTCBCOM Number of intra-cell handover attempt out of BCCH channel group, BCCHDTCB criteria. BCLOSSCOM Number of intra-cell handover attempt out of BCCH channel group, BCCHLOSS criteria. BCDTCBSUC Number of successful intra-cell handover out of BCCH channel group, BCCHDTCB criteria. BCLOSSSUC Number of successful intra-cell handover out of BCCH channel group, BCCHLOSS criteria. The intra cell handover feature can be triggered by bad quality (if the signal strength is above predefined levels), which in most cases means a high level of interference. If the number of intra cell handovers due to bad quality become too high the cell- and/or frequency planning needs to be improved. In cells with congestion, intra cell handover should be switched off, as two TCHs are seized during the handover process. Another possible cause of intra cell handovers are the FR/HR changes due to the features Dynamic FR/HR Mode Adaptation and ABIS Triggered HR Allocation. The object type CLRATECHG contains counters to monitor the number of attempted and successful intra cell handovers due to these features. The FR to HR counters may be stepped both if the handover is triggered by cell load and if triggered by Abis load. HOATFRHRAMR Number of intra cell handover attempts, due to FR to HR channel rate change triggered by high cell load or high Abis load, made by a mobile capable of AMR Narrowband, but not capable of AMR Wideband. HOSUCFRHRAMR Number of successful intra cell handovers, due to FR to HR channel rate change triggered by high cell load or high Abis load, made by a mobile capable of AMR Narrowband, but not capable of AMR Wideband. 68 HOATFRHRAW Number of intra cell handover attempts, due to FR to HR channel rate change triggered by high cell load or high Abis load, made by an AMR Wideband capable mobile. HOSUCFRHRAW Number of successful intra cell handovers, due to FR to HR channel rate change triggered by high cell load or high Abis load, made by an AMR Wideband capable mobile. HOATFRHRNAMR Number of intra cell handover attempts, due to FR to HR channel rate change triggered by high cell load or high Abis load, made by a mobile not capable of AMR. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring HOSUCFRHRNAMR Number of successful intra cell handovers, due to FR to HR channel rate change triggered by high cell load or high Abis load, made by a mobile not capable of AMR. HOATHRFRAMR Number of Intra Cell Handover Attempts due to HR to FR channel rate change triggered by bad quality, made by an AMR capable mobile. HOSUCHRFRAMR Number of successful Intra Cell Handovers due to HR to FR channel rate change triggered by bad quality, made by an AMR capable mobile. HOATHRFRNAMR Number of Intra Cell Handover attempts due to HR to FR channel rate change triggered by bad quality, made by a mobile not capable of AMR. HOSUCHRFRNAMR Number of successful intra cell handovers, due to HR to FR channel rate change triggered by bad quality, made by a mobile not capable of AMR. ATAMRLDHRFRHO Number of intra cell handover attempts, due to HR to FR channel rate change triggered by low cell load and low Abis load, for AMR/HR calls. SUCAMRLDHRFRHO Number of successful intra cell handovers, due to HR to FR channel rate change triggered by low cell load and low Abis load, for AMR/HR calls. ATNAMRLDHRFRHO Number of intra cell handover attempts, due to HR to FR channel rate change triggered by low cell load and low Abis load, for non AMR/HR calls. SUCNAMRLDHRFRHO Number of successful intra cell handovers, due to HR to FR channel rate change triggered by low cell load and low Abis load, for non AMR/HR calls. The subset of the handovers that are caused by Abis congestion only are counted by the following counters in the object type CLRATECHG: AMRABHOSUCFRHR Number of successful intra cell handovers due to FR to HR channel rate change triggered by high Abis load, made by a mobile capable of AMR Narrowband, but not capable of AMR Wideband. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 69 User Description, Radio Network Statistics NAMRABHOSUCFRHR Number of successful intra cell handovers due to FR to HR channel rate change triggered by high Abis load by a mobile not capable of AMR. AWABHOSUCFRHR Number of successful intra cell handovers due to FR to HR channel rate change triggered by high Abis load, made by a mobile capable of AMR Wideband. Another reason for intra cell hand-over is channel repacking, see Reference [13]. The number of handovers due to channel repacking can be monitored by the following counter in the object type CELEVENTI: HOSUCTCHOPT Number of successful Intra Cell Handover due to TCH optimization. In terms of Intra cell hand-over due to HR packing the following counters in the object type CELEVENTI can be used to monitor this function. These counters may be stepped both if the HR packing is triggered by cell load and if triggered by Abis load. 5.7.3 HOATTHRPACK Number of intra cell handover attempts due to half rate packing. HOSUCHRPACK Number of successful intra cell handovers due to half rate packing. Dynamic BTS and MS Power Control When tuning the power control features, general performance measures related to quality, such as dropped calls or normal disconnections at bad quality or low signal strength, are used (see Section 5.5 on page 49). A high rate of intra cell handovers or bad quality can indicate interference. It is also very important to get information about the subscriber perceived quality. For this purpose, the recording functions MRR, CTR, MTR and TEMS can be used. With these tools, up- and downlink quality, received signal strength and the distribution of used power levels could be monitored, see Section 3 on page 5. The following counters in object type CELLDYNPC are on cell level and used for the optional feature Reduced Power Level After Handover. Using these counters it is possible to monitor the accumulated initial down regulation after handover for BTS and MS power control, respectively. BSINITDREGHO Accumulated initial BTS power down regulation after handover, in dB. MSINITDREGHO Accumulated initial MS power down regulation after handover in, dB. Due to reduced interference when using this feature in the Radio Network, the KPI for SQI is expected to improve. To what extent is highly depending on radio 70 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring network design and existing frequency plan. Also note that no power levels are affected until the handover is completed, i.e. FACCH signalling is not affected. 5.7.4 Immediate Assignment on TCH The object type CLTCH contains the counter TCHSIG which counts the number of TCH connections used for signalling. TCHSIG Number of TCH connections for signalling. Object type CLTCH. TFNRELCONG Number of released full-rate TCH used for signalling in underlaid subcell, due to radio resource congestion (TCH, transcoder etc.), TFNRELCONGSUBfor overlaid. Object type CELTCHF. Corresponding counters for half-rate exist and is called THNRELCONGand THNRELCONGSUBrespectively. If the percentage of TCH connections used for signalling becomes too high, more SDCCH channels need to be defined. However, this depends on the channel allocation strategy and how the feature adaptive configuration of logical channels is used. 5.7.5 Assignment to Other Cell The object type NICELASS contains counters regarding assignment to other cell. For external cell the object type is NECELASS. HOASBCL Number of assignment attempts to better cell. Corresponding counter for assignment to worse cell is HOASWCL . HOSUCBCL Number of successful assignment attempts to better cell. Corresponding counter for assignment to worse cell is HOSUCWCL. For instance, the success rate for assignment to better cell can be calculated accordingly: HAbeSUC = HOSUCBCL HOASBCL 3 100 [%] Equation 35 Success Rate for Assignment to Better Cell The success rate calculation for assignment to worse cell is similar. In order to compare the assignments with the total number of assignments, TFCASSALL, TFCASSALLSUB etc. must be included. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 71 User Description, Radio Network Statistics 5.7.6 Dynamic Overlaid/Underlaid Subcell The object type CELEVENTS contains counters regarding handovers between underlaid and overlaid subcell. HOAATOL Number of handover attempts from underlaid to overlaid subcell. The corresponding counter for handover to underlaid subcell is called HOAATUL. HOSUCOL Number of successful assignment attempts to overlaid subcell. The corresponding counter for underlaid subcell is called HOSUCUL. HOATTULMAXIHO Number of handover attempts from overlaid to underlaid subcell due to maximum number of intracell handovers in overlaid subcell. HOSUCULMAXIHO Number of successful handover attempts from overlaid to underlaid subcell due to maximum number of intracell handovers in overlaid subcell. HOATTOLMAXIHO Number of handover attempts from underlaid to overlaid subcell due to maximum number of intracell handovers in underlaid subcell. HOSUCOLMAXIHO Number of successful handover attempts from underlaid to overlaid subcell due to maximum number of intracell handovers in underlaid subcell. The success rate for handover from underlaid to overlaid subcell can be calculated accordingly: HOolSUC = HOSUCOL HOAATOL 3 100 [%] Equation 36 Success Rate for Handover From Underlaid Subcell to Overlaid Subcell Most of the drop, congestion and call setup counters are divided into subcell level. Those counters and related formulas are described in Section 5 on page 35. The object type CELEVENTSC contains counters related to additional reasons why subcell change to an underlaid subcell may occur. Note that the counters HOATTOL and HOSUCOL or HOAATUL and HOSUCUL are also stepped for each of these attempts and success respectively. 72 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring 5.7.7 LOLCOMUL Subcell change attempts from overlaid to underlaid when reaching LOL criteria for subcell change. LOLSUCUL Successful subcell changes from overlaid to underlaid when the LOL criterion was the reason for the subcell change. DTCBCOMUL Subcell change attempts from overlaid to underlaid when reaching DTCB criteria for subcell change. DTCBSUCUL Successful subcell changes from overlaid to underlaid when the DTCB criterion was the reason for the subcell change. TAOLCOMUL Subcell change attempts from overlaid to underlaid when reaching TAOL criteria for subcell change. TAOLSUCUL Successful subcell changes from overlaid to underlaid when the TAOL criterion was the reason for the subcell change. SCLDCOMUL Subcell change attempts from overlaid to underlaid due to dynamic underlaid/overlaid subcell load distribution. SCLDSUCUL Successful subcell changes from overlaid to underlaid when subcell load distribution (SCLD) was the reason for change. OLSCLDCOM Subcell change attempts from underlaid to overlaid when subcell load distribution (SCLD) was the reason for change. OLSCLDSUC Successful subcell changes from underlaid to overlaid when subcell load distribution (SCLD) was the reason for change Hierarchical Cell Structure Counters in the object types CELLHCS and NICELHO/NECELHO can be used to monitor how HCS affects the traffic distribution: HOTOHCS Number of handover attempts due to HCS. LOCEVAL Accumulated number of locating evaluations. BRHILAYER Accumulated number of locating evaluations where HCS ranking differs from basic ranking. TIMEHCSOUT Accumulated time in seconds when the servings cells channel availability is below or equal to HCSOUT. Note that the counter is only stepped it the feature HCS Traffic Distribution is active. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 73 User Description, Radio Network Statistics An important measure in multi layered networks is the traffic that the lower layer cell captures from the higher layer cells due to HCS. The traffic off-load can be expressed as: ER 3 100 [%] HCSoffload = BRHILAY LOCEV AL Equation 37 Traffic off-Load Due to HCS The formula together with the counter HOTOHCS above can be used when tuning the thresholds for HCS handover. When HCS is used to priorities a cell, e.g. a layer 1 microcell, the handovers triggered by quality becomes especially important to monitor since the handovers out of the microcell are caused by bad quality to a larger extent. Observe, that the statistics regarding HCS is highly dependent on parameter settings. The object type NICELHOEX contains counters for monitoring the handover attempts and successful handovers at high handover rate. The corresponding object type for external cells is NECELHOEX. 5.7.8 HOATTHR Number of handover attempts at high handover rate. HOSUCHR Number of successful handovers at high handover rate. Multiband Operation There exists an object type, CELTCHFP, for the primary GSM 900 band. Statistics about full-rate TCH channels in the primary 900 band can be retrieved which make it easier to differ between the primary 900 and the extended band. The counters can also be useful in dual band networks, at least for statistics on BSC level. The counters in object type CELTCHFP give valuable full-rate traffic information about the primary GSM 900 band. Some important counters: TFESTPGSM Number of connections successfully established, TFESTPGSMSUBfor overlaid subcells. TFDROPPGSM Number of dropped connections due to failure, TFDROPPGSMSUBfor overlaid subcells. TFCONGPGSM Congestion time, TFCONGPGSMSUB for overlaid subcells. TFTRALPACC Traffic level accumulator, TFTRALPACCSUBfor overlaid subcells. If statistics are collected on BSC level the performance of the 900 part of the dual band network can be filtered out in an easy way. Other counters to use are those concerning hierarchical cell structure or cell load sharing which are indirectly related to multiband. 74 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring Handover statistics between two bands is treated in the same way as in single band systems. In order to check statistics for multiband relations, those must be specially picked out and then analyzed as normal relations, containing exactly the same measurements. 5.7.9 Idle Channel Measurement For idle channel measurement there are four object types for FR/HR and underlaid/overlaid, e.g. IDLEUTCHF (TCH/F in underlaid subcell). In this object type there are counters for the accumulated number of idle channels in each interference band. Accumulated number of idle TCH/F in the underlaid subcell in interference band 1. The corresponding counter for half-rate and overlaid subcell is ITHOSIB1. ITFUSIB1 Shown below is the percentage of idle channels in interference band 1 out of the total idle channels. The same measure can be calculated for interference band 2 to 5. As a help expression, the total number of idle full-rate TCH in underlaid subcell is calculated first. X 5 IT F U tot = IT F U SIBn N =1 Equation 38 ICM f u1 = Equation 39 5.7.10 Total Number of Idle Full-Rate TCH Channels in Underlaid Subcell IT F U SIB 1 IT F U tot 3 100 [%] Percentage of Idle Full-Rate TCH in Underlaid Subcell in Interference Band 1 Cell Load Sharing The object type CELEVENTH contains counters related to the Cell Load Sharing (CLS) feature. CLSTIME Accumulated time in seconds when CLS evaluation is performed in the cell. TOTCLSTIME Total time for the CLS feature being activate in seconds. HOATTLS Handover attempts due to CLS. HOSUCLS Successful handovers due to CLS. The percentage of CLS handovers out of all handovers during busy hour and the percentage of the time when CLS evaluation was performed could 216/1553-HSC 103 12/16 Uen E | 2010-11-10 75 User Description, Radio Network Statistics for example be monitored. The number of attempts leading to a successful handover due to CLS is written as follows. HOsucLS = HOSUCLS HOATTLS 3 100 [%] Equation 40 Success Rate for Handovers Due to Cell Load Sharing If needed, the number of CLS handovers can be compared with the total number of handovers. These counters are described in Section 5.5.6 on page 56. 5.7.11 High Speed Circuit Switch Data The object type BSCMSLOT contains several counters for monitoring of High Speed Circuit Switch Data (HSCSD) channels. on BSC level. TMASSALL Assignment attempts for multislot connections. TMCASSALL Successful assignment attempts for multislot connections. TMHOATT Handover attempts for multislot connections. TMHOSUCC Successful handovers for multislot connections. TMCHREQACC Number of requested channels for multislot connections. TMCHRECACC Number of received channels for multislot connections. TMCNCMATT Configuration change attempts for multislot connections initiated by the MSC. TMCNCBATT Configuration change attempts for multislot connections initiated by the BSC. The attempts are made internal in the BSC and do not necessarily lead to sending any messages to the MS or the MSC. In a situation where a connection has less channels than required for a longer period, the counter will be incremented every 5 seconds. Stepping of counters in CELTCHF in the case of an allocation attempt of TCH/F for an HSCSD connection: 76 • The counters TFCALLS and TFCALLSSUB are stepped by one regardless of the number of channels requested in the allocation attempt. The counters are not incremented for configuration change attempts for multislot connections initiated by the MSC or by the BSC. • The counters TFCONGSAS, TFCONGSASSUB, TFCONGSHO and TFCONGSHOSUB are stepped by one only if the allocation fails, that is no new channels allocated. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring • The counters are not incremented for configuration change attempts for multislot connections initiated by the MSC or by the BSC. The object type CELLHSCSD contains counters for monitoring seizure of different channels in overlaid and underlaid subcells. TFHSCSDMAIN Traffic level accumulator for seized HSCSD main channels. TFHSCSDNESEC Traffic level accumulator for seized non essential HSCSD secondary channels. TFHSCSDESEC Traffic level accumulator for seized essential HSCSD secondary channels. The corresponding counters for an overlaid subcell are TFHSCSDMAINSUB, TFHSCSDNESECSUBand TFHSCSDESECSUB. 5.7.12 Enhanced Multi-Level Precedence and Preemption The object type PREEMP contains three counters related to the enhanced priority handling feature. HOATTPH Number of handover attempts due to preemption. DISPH Number of disconnections due to preemption. FAILPH Number of preemption failures. These counters should be monitored when using different priority levels for different subscriber segments. Additional information about the performance for different subscriber segments could be monitored by means of the recording function Channel Event Recording (CER), see Reference [6]. 5.7.13 Adaptive Configuration of Logical Channels The object type CELLCONF contains two counters for channel re-configuration between TCH and SDCCH. CONFATTC Number of all re-configuration attempts from TCH to SDCCH. CONFATTT Number of all re-configuration attempts from SDCCH to TCH. When analyzing the counters above it is important to have the chosen SDCCH dimensioning strategy clear. If for example the chosen strategy is to keep as many TCHs configured as possible the counters above will be stepped many times when the SDCCH traffic is changing to high and low values during the day. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 77 User Description, Radio Network Statistics If the strategy is to dimension the network with the needed amount of SDCCH sub-channels, the counters can be used for finding cells which need more SDCCH sub-channels. The counters can also be used for optimizing the feature Adaptive configuration of logical channels per cell. 5.7.14 Dual Band MS Statistics The object type CELLDUALT contains counters that are incremented for MSs capable of dual band 900/1800. If the MSs can handle more bands than 900/1800 they will also be considered in the CELLDUALT, since they can handle both 900 and 1800. TFDUALTRALACC Traffic level accumulator for dual band MSs. The number of accumulations of the counter is counted in TFNSCAN in the object type CELTCHF, see Section 5.3 on page 36. TFDUALNDROP Dropped dual band MS connections due to failure. TFDUALCASSALL Assignment complete for all (dual band) MS power classes. TFDUALASSALL Assignment attempts for all (dual band) MS power classes. The following formula shows the average TCH full-rate traffic level in a cell, generated by dual band MSs, and the percentage of the TCH traffic level that are generated by dual band MSs. T F dualT RAF F Equation 41 RALACC = T F DUALT [Erlang] T F N SCAN TCH Dual Band MS Traffic Level T F dualRAT E = Equation 42 T F dualT RAF F 3 100 [%] T F traff + T Htraff Percentage TCH Traffic Level Generated by Dual Band Mss An accurate measure of the dual band MS drop rate on cell level is not possible to obtain, since this requires handover information for the dual band MSs. It is therefore recommended to only use the dual band drop rate counter when analyzing drop rate performance on BSC level. 5.7.15 Adaptive Multi Rate A number of counters are available to help monitor the service provided to adaptive multi rate users. Adaptive multi rate (AMR Narrowband) is also 78 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring referred to as Speech Version 3, while AMR Wideband is also refered to as Speech Version 5. 5.7.15.1 Accessibility The counters provided for monitoring TCH connections (call attempts, congestion and traffic levels) specifically for Speech Version 1 and Speech Version 2 are replicated for AMR full-rate, AMR half-rate and AMR wideband in the object types CLTCHFV3, CLTCHHV3 and CLTCHFV5, respectively. Note that the corresponding counters for all TCH full-rate connections (CELTCHF) and TCH half-rate connections (CELTCHH) are still stepped for AMR. 5.7.15.2 Retainability The object types CLTCHDRAW, CLTCHDRAF and CLTCHDRAH contain per cell counters for the drop call reasons specifically for AMR wideband, AMR full-rate and half-rate. These are further described in Section 5.5.3 on page 54. 5.7.15.3 Speech Quality The speech quality supervision function is extended with counters specifically for AMR Narrowband and AMR Wideband. More details are given in Section 5.6 on page 58. Finally, the object types CLTCHFV3C and CLTCHHV3C contain counters per cell for AMR codec mode utilization, while the object type CL TCHFV5C contain counters per cell for AMR Wideband codec mode utilization. These allow, for a specific direction (DL/UL) and AMR Narrowband version (FR/HR) and AMR Wideband, to calculate a distribution of the fraction of time spent in each codec mode of the total time. Since the use of a specific codec mode corresponds to a certain C/I range this can also be interpreted as a basic distribution of the radio link quality in the cell. Improving the radio link quality in the cell will reduce the time spent in the lower codec modes and improve the speech quality as perceived by the users. TFV3CM1DL Time spent on full rate AMR (Speech Version 3) codec mode 1 (of the codec set as defined in the BSC) downlink. TFV3CM2DL is the corresponding counter for AMR codec mode 2. TFV3CM3DL is the corresponding counter for AMR codec mode 3. TFV3CM4DL is the corresponding counter for AMR codec mode 4. TFV3CM1UL Time spent on full rate AMR (Speech Version 3) codec mode 1 uplink. TFV3CM2UL is the corresponding counter for AMR codec mode 2. TFV3CM3UL is the corresponding counter for AMR codec mode 3. TFV3CM4UL is the corresponding counter for AMR codec mode 4. THV3CM1DL Time spent on half rate AMR (Speech Version 3) codec mode 1 downlink. THV3CM2DL is the corresponding 216/1553-HSC 103 12/16 Uen E | 2010-11-10 79 User Description, Radio Network Statistics counter for AMR codec mode 2. THV3CM3DL is the corresponding counter for AMR codec mode 3. THV3CM4DL is the corresponding counter for AMR codec mode 4. 5.7.16 THV3CM1UL Time spent on half rate AMR (Speech Version 3) codec mode 1 uplink. THV3CM2UL is the corresponding counter for AMR codec mode 2. THV3CM3UL is the corresponding counter for AMR codec mode 3. THV3CM4UL is the corresponding counter for AMR codec mode 4. TFV5CM1DL Time spent on full rate AMR Wideband (Speech Version 5) codec mode 1 (of the codec set as defined in the BSC) downlink. TFV5CM2DL is the corresponding counter for AMR Wideband (Speech Version 5) codec mode 2. TFV5CM3DL is the corresponding counter for AMR Wideband (Speech Version 5) codec mode 3. TFV5CM1UL Time spent on full rate AMR Wideband (Speech Version 5) codec mode 1 uplink. TFV5CM2UL is the corresponding counter for AMR Wideband (Speech Version 5) codec mode 2. TFV5CM3UL is the corresponding counter for AMR Wideband (Speech Version 5) codec mode 3. Prioritized MS Queuing (PMSQ) The object type CELLMSQ contains 6 counters to monitor the prioritized MS Queuing feature per cell. 80 NQPCCNT The total number of queued GSM priority connections. Only stepped once per received Assignment Request message where the MS gets queued. RQHIGHCNT The total number of GSM priority connections removed from the queue due to the arrival of a higher ranked GSM or UTRAN priority connection (and the queue was full). NIQLOWCNT The total number of GSM priority connections not inserted in the queue when the queue was full, due to too low ranking. RQT11CNT The total number of GSM priority connections removed from the queue due to time-out of GSM queuing timer T11. NPCALLOCCNT The total number of times a GSM or UTRAN non-priority connection allocates a channel in a cell where a queue exists. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring RQLOSSCNT The total number of queued GSM priority connections released from the queue due to loss of radio contact with the MS or because the Service User abandon the call. NQPCUTRANCNT Number of queued UTRAN Priority Connections. The counter is only stepped once per received HANDOVER REQUEST message where MS gets queued. RQHIUTRANCNT Number of UTRAN Priority Connections removed from the queue when queue is full, due to arrival of a higher ranked GSM or UTRAN Priority Connection. NIQLOWUTRANCNT Number of UTRAN Priority Connections not inserted in the queue when queue is full, due to low ranking. RQTQHOCNT Number of UTRAN Priority Connections that have been removed from the queue due to timeout of TQHO. RQLOSSUTRANCNT Number of queued UTRAN Priority Connections that are released due to reception of CLEAR COMMAND message from the MSC. 5.7.17 Counters for Channel Group Zero (CHGRP0) The counters described below makes it possible to monitor selected performance indicators separately for channel group zero. A limited number of counters are provided in three areas: Accessibility Separate traffic level counters for full-rate, half-rate and PS traffic. Congestion counters would not be relevant for an individual channel group. Retainability Separate dropped call and reason for drop counters for full-rate and half-rate. Quality A full set of Speech Quality Supervision counters plus intra-cell handover counters. These counters are useful when the CHGRP0 frequency plan is different compared to the rest of the cell/subcell. For example a cell that has a underlaid/overlaid subcell structure where the underlaid subcell contains both CHGRP1, which uses a hopping 1/1 tight frequency reuse, and CHGRP0, which uses a non-hopping 4/12 frequency plan for the BCCH carrier. The CHGRP1 performance can be extracted by subtracting the CHGRP0 counter values from the equivalent underlaid subcell counter values. There are counters for SQI DL separately for channel group zero in the object type CHGRP0SQI. Object type: CHGRP0F. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 81 User Description, Radio Network Statistics Title: Counters for monitoring selected performance indicators separately for channel group zero.The counters are per cell. 82 TFTRALACC0 Full-rate traffic level accumulator. TAVACC0 Number of available TCH accumulator. Both FR and HR. TACCSCAN0 Number of scans taken for traffic level accumulators in channel group zero. Both FR and HR. ALLPDCHSCAN0 Number accumulations of allocated PDCHs in channel group zero. ALLPDCHACC0 Number of allocated PDCHs on channel group zero accumulator. TFNDROP0 Number of dropped TCH/F connections in channel group zero. TFQADLDIS0 Number of dropped TCH/F connections at bad quality downlink. TFQAULDIS0 Number of dropped TCH/F connections at bad quality uplink. TFQABLDIS0 Number of dropped TCH/F connections at bad quality both links. TFFERDLDIS0 Number of dropped TCH/F connections at high FER downlink TFFERULDIS0 Number of dropped TCH/F connections at high FER uplink TFFERBLDIS0 Number of dropped TCH/F connections at high FER both links TFSSDLDIS0 Number of dropped TCH/F connections at low signal strength downlink. TFSSULDIS0 Number of dropped TCH/F connections at low signal strength uplink. TFSSBLDIS0 Number of dropped TCH/F connections at low signal strength both links. TFSUDLOS0 Number of suddenly lost TCH/F connections. TFTADIS0 Number of dropped TCH/F connections at excessive TA. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring TSQ0GOOD Number of measurements with good speech quality UL in channel group zero when the channel rates are FR and HR and when the speech version is SPV1 or SPV2. TSQ0AFGOOD Number of measurements with good speech quality UL in channel group zero when an AMR Narrowband codec is used and the channel rate is FR. TSQ0AWGOOD Number of measurements with good speech quality UL in channel group zero when an AMR Wideband codec is used. TSQ0ACCPT Number of measurements with acceptable speech quality UL in channel group zero when the channel rates are FR and HR and when the speech version is SPV1 or SPV2. TSQ0AFACCPT Number of measurements with acceptable speech quality UL in channel group zero when an AMR Narrowband codec is used and the channel rate is FR. TSQ0AWACCPT Number of measurements with acceptable speech quality UL in channel group zero when an AMR Wideband codec is used. TSQ0BAD Number of measurements with unsatisfactory speech quality UL in channel group zero when the channel rates are FR and HR and when the speech version is SPV1 or SPV2. TSQ0AFBAD Number of measurements with unsatisfactory speech quality UL in channel group zero when an AMR Narrowband codec is used and the channel rate is FR. TSQ0AWBAD Number of measurements with unsatisfactory speech quality UL in channel group zero when an AMR Wideband codec is used. Object type: CHGRP0H. Title: Counters for monitoring selected performance indicators separately for channel group zero, counters are per cell. THTRALACC0 Half-rate traffic level accumulator. THNDROP0 Number of dropped TCH/H connections in channel group zero. THQADLDIS0 Number of dropped TCH/H connections at bad quality downlink. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 83 User Description, Radio Network Statistics THQAULDIS0 Number of dropped TCH/H connections at bad quality uplink. THQABLDIS0 Number of dropped TCH/H connections at bad quality both links. THFERDLDIS0 Number of dropped TCH/H connections at high FER downlink THFERULDIS0 Number of dropped TCH/H connections at high FER uplink THFERBLDIS0 Number of dropped TCH/H connections at high FER both links THSSDLDIS0 Number of dropped TCH/H connections at low signal strength downlink. THSSULDIS0 Number of dropped TCH/H connections at low signal strength uplink. THSSBLDIS0 Number of dropped TCH/H connections at low signal strength both links. THSUDLOS0 Number of suddenly lost TCH/H connections. THTADIS0 Number of dropped TCH/H connections at excessive TA. HOINUQA0 Number of intra cell handover attempts at bad uplink quality. Both FR and HR. HOINDQA0 Number of intra cell handover attempts at bad downlink quality. Both FR and HR. HOINBQA0 Number of intra cell handover attempts at bad quality UL on both links. Both FR and HR. TSQ0AHGOOD Number of measurements with good speech quality UL in channel group zero when an AMR Narrowband codec is used and the channel rate is HR. TSQ0AHACCPT Number of measurements with acceptable speech quality UL in channel group zero when an AMR Narrowband codec is used and the channel rate is HR. TSQ0AHBAD Number of measurements with unsatisfactory speech quality UL in channel group zero when an AMR Narrowband codec is used and the channel rate is HR. Object type: CHGRP0SQI. 84 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring Title: Counters for monitoring selected performance indicators separately for channel group zero. Counters are per cell. TSQ0GOODDL Number of measurements with good speech quality DL in channel group zero when channel rates are FR and HR and when the speech version is SPV1 or SPV2. TSQ0ACCPTDL Number of measurements with acceptable speech quality DL in channel group zero when channel rates are FR and HR and when the speech version is SPV1 or SPV2. TSQ0BADDL Number of measurements with unsatisfactory speech quality in DL channel group zero when channel rates are FR and HR and when the speech version is SPV1 or SPV2. TSQ0AFGOODDL Number of measurements with good speech quality DL in channel group zero when an AMR Narrowband codec is used and the channel rate is FR. TSQ0AFACCPTDL Number of measurements with acceptable speech quality DL in channel group zero when an AMR Narrowband codec is used and the channel rate is FR. TSQ0AFBADDL Number of measurements with unsatisfactory speech quality DL in channel group zero when an AMR Narrowband codec is used and the channel rate is FR. TSQ0AWGOODDL Number of measurements with good speech quality DL in channel group zero when an AMR Wideband codec is used and the channel rate is FR. TSQ0AWACCPTDL Number of measurements with acceptable speech quality DL in channel group zero when an AMR Wideband codec is used and the channel rate is FR. TSQ0AWBADDL Number of measurements with unsatisfactory speech quality DL in channel group zero when an AMR Wideband codec is used and the channel rate is FR. TSQ0AHGOODDL Number of measurements with good speech quality DL in channel group zero when an AMR Narrowband codec is used and the channel rate is HR. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 85 User Description, Radio Network Statistics TSQ0AHACCPTDL Number of measurements with acceptable speech quality DL in channel group zero when an AMR Narrowband codec is used and the channel rate is HR. TSQ0AHBADDL 5.7.18 Number of measurements with unsatisfactory speech quality DL in channel group zero when an AMR Narrowband codec is used and the channel rate is HR. Dual Transfer Mode (DTM) The object type CLDTMEST contains per cell counters to monitor DTM connection setup attempts and successful establishments per channel service. TDTMATT Number of attempts to establish a DTM connection, stepped before the MS is allowed to enter DTM mode. TDTMALLOCATT Number of attempts to allocate channels for a DTM connection. This counter is stepped when all checks to see if the MS is allowed to enter DTM are performed. TFSPV1DTMSUC Number of successful establishments of a DTM connection, TCH/FR Speech Version 1. TFSPV2DTMSUC Number of successful establishments of a DTM connection, TCH/FR Speech Version 2. TFSPV3DTMSUC Number of successful establishments of a DTM connection, TCH/FR Speech Version 3. TFSPV5DTMSUC Number of successful establishments of a DTM connection, TCH/FR Speech Version 5. THSPV1DTMSUC Number of successful establishments of a DTM connection, TCH/HR Speech Version 1. THSPV3DTMSUC Number of successful establishments of a DTM connection, TCH/HR Speech Version 3. The percentage of all DTM establishments that result in a CS half rate connection can be calculated as: DTMcsHR = Equation 43 P (THSPV xDTMSUC ) =[1;3] P (TFSPVxyDTMSUC ) + P (THSPV xDTMSUC ) 3 100 [%] y=[103;5] x=[1;3] Percentage of All DTM Establishments that Result in a CS Half Rate Connection A failure to allocate a DTM connection could be due to lack of PS or CS resources. The percentage of all DTM allocation attempts that are successful calculated as: 86 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring DTMalSUC = y Equation 44 P (TFSPV yDTMSUC ) + P (THSPV xDTMSUC ) =[103 5] =[1 3] ; x ; TDTMALLOCAT 3 100 [%] DTM Allocation Success Rate. Other DTM related counters are described in Section 6.17.10 on page 179. 5.7.19 Counters for Single Antenna Interference Cancellation (SAIC) Mobiles BSS provides statistics and measurements specifically for SAIC capable mobiles. These measures can be used to monitor the behavior of SAIC capable mobiles in a network and to determine the traffic level penetration of SAIC capable mobiles. It is believed that a high penetration of SAIC mobiles will allow for making tighter frequency planning of the network and simulation have shown that the speech capacity gain is: about 6% at a SAIC terminal penetration of 10%, about 37% at a SAIC terminal penetration of 50%, about 99% at a SAIC terminal penetration of 100%. Traffic level penetration of SAIC mobiles in CS domain The object type CELLMSCAP contains per cell counters to monitor the traffic level penetration of SAIC capable mobiles in the CS area. SAICTRALACC Traffic level counter (accumulation counter) that gives continuous information about the number of active SAIC (Single Antenna Interference Cancellation) capable MSs per cell. SAIC is in 3GPP TS 24.008 called “Downlink Advanced Receiver Performance”. The corresponding internal traffic level counter is incremented when Classmark 3 information for a SAIC capable MS is received. Note: SAICTRALACC treats SAIC terminals with both channel rate FR and HR. THSAICTRALACC Traffic level accumulator for SAIC capable MSs with channel rate HR. SAICSCAN Number of accumulations of the counter SAICTRALACC and THSAICTRALACC, respectively. The Traffic Level penetration of SAIC capable mobiles in the CS domain can be calculated as: TrafLevelSAICcs = SAICTRALACC SAICSCAN [Erlang] Equation 45 Traffic level penetration (in terms of ‘number of SAIC mobiles with an established connection’) of SAIC capable terminals with channel rate FR and HR in the CS domain. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 87 User Description, Radio Network Statistics Traffic level penetration of SAIC mobiles in PS domain The object type CELLGPRS3 contains 2 per cell counters to monitor the user data volume generated by SAIC capable mobiles in the PS area. These counters works in a similar fashion to the existing counters for total LLC data volume in order to be comparable, but is only tracking data volume generated by terminals which are SAIC capable in the PS area. ULSAICVOL The LLC user data volume generated by SAIC capable mobiles on the uplink. (GMM/SM signalling is not included). Note: The counter ULSAICVOL includes transfers for both DTM and non-DTM. DLSAICVOL The LLC user data volume generated by SAIC capable mobiles on the downlink. (GMM/SM signalling is not included). Note: The counter DLSAICVOL includes transfers for both DTM and non-DTM. In order to determine the traffic level penetration, or rather the percentage of data volume generated by SAIC capable terminals, in the PS domain the following formulas for UL and DL, respectively, can be used: UL = ULSAICV OL 1000 3 ULvol 3 100 [%] W here : ULvol = (ULINT BGV OL + V OLULST RACC + LLCV OLULEIT + DT MULST RDAT A) Equation 46 Traffic level penetration (in terms of ‘LLC user data volume generated’) of SAIC capable terminals in the PS domain. DL = DLSAICV OL 1000 3 (DLINT BGV OL + DLST RV OL) 3 100 [%] Equation 47 Traffic level penetration (in terms of ‘LLC user data volume generated’) of SAIC capable terminals in the PS domain. In order to determine how SAIC mobiles behave in the network, quality measurements are available using Event Based Monitoring. A selected set of monitors as described below can be filtered on SAIC capable mobiles in order to provide valuable quality measurements for SAIC terminals. Quality measurements related to SAIC capable mobiles in the CS domain In the CS domain, the network is made aware of is a terminal is SAIC capable or not, via the ‘Classmark 3 INFORMATION’ message. This information is handled in the system using the event ‘Classmark 3 INFORMATION’. For a certain set of quality monitors (see below), it is possible to filter on the following values: • 88 SAIC 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring • non-SAIC • All The following monitors have the above filters: • RXQUAL UL/DL • FER DL/UL (%) • HandOver Attempts (#) • Handover Success (%) • Extended Drop (Cause %)* • TCH Drop (%)* • TCH Drop (#)* Note: * In addition, a special case applies to the drop monitors, which have been updated to also allow filtering on the following codec modes: HR, FR, EFR, AMRHR and AMRFR, respectively. Finally, measures for ‘msPwr’ and ‘bsPwr reduction’ are available through Raw Event Data Export. Quality measurements related to SAIC capable mobiles in the PS domain In the PS domain, the network is made aware of if a terminal is SAIC capable or not, via the ‘MS RAC’ message. This information is handled in the system using the following events: ‘‘TBF Ends’, 'Data Activity Ends' and 'GPRS Flush Event’, respectively. For a certain set of quality monitors (see below), it is possible to filter on the following values: • SAIC • non-SAIC • All • Unknown’ (this value is used if the MS RAC has not been received in the PCU). The following monitors have the above filters: • IP Throughput (PFC) • Radio Link Bit rate • BEP at CRS (GSM) • RXQUAL at CRS (GSM) 216/1553-HSC 103 12/16 Uen E | 2010-11-10 89 User Description, Radio Network Statistics 5.7.20 • Abnormal TBF Releases (cause #) • Abnormal TBF Releases, per TBF minute (#) MCPA Related Statistics The counters in object type MOMCTR are applicable to TRXs running on MCPA based radio units. For details please see MCPA Guideline, Reference [45]. Note that the term MCTR is equivalent to MCPA in this context. The following counters are used to evaluate and dimension the cells so that enough power is available for all TRXs. For example, at low average power use it may be possible to configure another TRX for this MCPA. At high average power use it may be necessary to add another MCPA to the cell. BPWRO100 Number of bursts with a nominal power > 100% of the available power. BPWR90100 Number of bursts with a nominal power <= 100% and > 90% of the available power. BPWR8090 Number of bursts with a nominal power <= 90% and > 80% of the available power. BPWR7080 Number of bursts with a nominal power <= 80% and > 70% of the available power. BPWR6070 Number of bursts with a nominal power <= 70% and > 60% of the available power. BPWR5060 Number of bursts with a nominal power <= 60% and > 50% of the available power. BPWR0050 Number of bursts with a nominal power <= 50% of the available power. Below counters are listed with can be used to find possible impact from too high average power use, that is power overbooking (under dimensioning). The effect of too much power overbooking is that some DL bursts must be sent with lower power than intended. Normally the MCPAs will handle power overbooking well so that no power reduction is needed, but at times or at too much power overbooking the DL bursts with lowest priority will be power reduced (backed off). PS bursts have lowest priority and are backed off first. 90 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM Radio Network Performance Monitoring Note: Please note that: - if PDCH bursts are backed off much and/or often it could be a reason for reduced DL throughput, and possibly increased IP transfer interrupts DL. - if TCH bursts are backed off much and/or often it could be a reason for worsened DL speech quality. - if SDCCH bursts are backed off much and/or often it could be a reason for worsened SDCCH handover success rate. - other bursts includes BCCH, SACCH and FACCH bursts. These bursts have the highest priorities, and should normally not be backed of. However, if these bursts are backed of much and/or often it could be a reason for worsened TCH handover success rate or increased drop call rate. NUMTCHB Total number of TCH bursts. NUMTCHBRED Number of TCH bursts with reduced power due to power backoff. ACCTCHBREDDB Accumulated TCH power reduction in dB. NUMPDCHB Total number of PDCH bursts. NUMPDCHBRED Number of PDCH bursts with reduced power due to power backoff. ACCPDCHBREDDB Accumulated PDCH power reduction in dB. NUMOB Total number of other bursts. NUMOBRED Number of other bursts with reduced power due to power backoff. ACCOBREDDB Accumulated other power reduction in dB. NUMSDCCHB Total number of SDCCH bursts NUMSDCCHBRED Number of SDCCH bursts with reduced power due to power backoff ACCSDCCHBREDDB Accumulated SDCCH power reduction in dB 216/1553-HSC 103 12/16 Uen E | 2010-11-10 91 User Description, Radio Network Statistics 92 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6 GPRS/EGPRS Radio Network Performance Monitoring 6.1 Introduction In the telecom world we are used to defining network performance in terms of accessibility, retainability and integrity (see Section 5.1 on page 35). These terms work well for circuit switched networks; accessibility relates to blocked calls, retainability to dropped calls and integrity to speech quality. All of these can be measured in the BSS and roughly translated into a user perception of service quality. However, for packet switched networks, it is much more difficult to define STS counters in the BSS and relate these to the users perception of service quality. There are two main reasons for this: • The GPRS/EGPRS system has many layers of protocols. A session where a TBF is dropped for some reason, a retainability problem on BSS level, will normally be kept alive by TCP until a new TBF is established. To the user this seems like an integrity problem, one session that included a short delay. • The GPRS/EGPRS network is a bearer for a number of different applications. These are affected by events in the radio network in different ways. For example if the BSS failed to transfer any data for 5 seconds this would appear as a serious performance problem to a WAP user. It would hardly be noticed by a user performing downloading of e-mails in the background. The terms accessibility, retainability and integrity can be applied to the GPRS/EGPRS system, but only on higher layers, and by considering events, which are invisible to the BSS. A full set of end-to-end KPIs have been defined and are available from Ericsson. None of these can be fully measured in the BSS. Basically all IP service KPIs in BSS will be experienced as integrity problems to the end user. Rather the counters focus on the main task of the BSS which is the transfer of IP packets between the core network and the GPRS/EGPRS terminals. The counters are grouped into three areas: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 93 User Description, Radio Network Statistics Level one performance indicators These counters are directly related to the ability of the BSS to transport IP packets. Typically they are sets of counters that focus on one area of BSS performance (which could usually be affected by a number of different factors) which impacts the user perception of the service. For example the IP throughput counters on cell level measure the speed with which the BSS can transfer IP packets. Level two performance indicators These counters are indirectly related to the ability of the BSS to transport IP packets. They should be used for trouble-shooting purposes to identify the specific factors that are causing the level one indicators to show poor performance. For example the GPRS traffic load counters show how the number of users sharing the available PDCHs is affecting the measured IP throughput. They should not be used on their own for any dimensioning purposes. Additional performance indicators Are usually for monitoring of specific features and impacts. The figure below illustrates how the STS counters are grouped into the three areas (along with the object type names): 94 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Level one BSS performance indicators IP throughput IP latency IP data volume - CELLQOSG - CELLGPRS3 & - CELLQOSEG GPRS - CELLGPRS4 availability - CELLQOSS - CELLGPRS3 - CLDTMQOS EIT transfer delay Streaming connection IP transfer interrupts UL - CELLEIT negotitations (MS to BSS connection) - CLQOSSCON - CELLGPRS2 - CLQOSSCON2 - CELLGPRSO IP transfer interrupts DL (IP buffer discards) - CELLGPRS2 - CELLGPRSO Trouble shooting performed with level two counters Level two BSS performance indicators Radio link quality - CELLGPRS - CELLGPRS2 - CELLGPRSO - RLINKBTR Multilsot utilisation (PDCH reservation) - TRAFGPRS2 - TRAFGPRS3 - CLDTMPER Additional BSS performance indicators PDCH allocation and pre-emption - CELLGPRS - CELLGPRSO Additional BSC counters for GPRS - BSCGPRS - BSCGPRS2 Figure 1 GPRS traffic load - TRAFDLGPRS - TRAFULGPRS Mobility - CELLGPRS2 Additional counters for streaming - CLQOSSCON - CLQOSSCON2 - DELSTRTBF Counters for TBF keep alive mechanisms - BSCGPRS CS traffic load - CELTCHF - CELTCHH - CLTCH PDCH allocation - CELLGPRS - CELLGPRSO GSL device utilisation - BSCGPRS RPP load - BSCGPRS2 - EMGPRS Counters for QoS feature on BSC level - BSCQOS CCCH load - CCCHLOAD - CELLPAG TBF establishment and release - CELLGPRS - CELLGPRS2 PCCCH load - CELLGPRS - CELLGPRS2 Additional counters for DTM - CLDTMQOS - CLDTMPER Flexible Abis for GPRS/EGPRS - CELLFLXAB Abis Optimization - SUPERCH The Structure for GPRS/EGPRS Counters with Object Types Of course there are other factors which will determine how the user perceives the overall GPRS/EGPRS service. For example the effects of higher layer protocols (TCP slow start for example) and the type of application being used (if it is delay sensitive or throughput sensitive for example). However such things are transparent to the BSS and therefore cannot be measured in the BSS. The figure below indicates the factors that can affect the users perception of the GPRS/EGPRS service. The factors that cannot be measured in the BSS are in grey text: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 95 User Description, Radio Network Statistics TCP/IP effects Quality of the radio link Factors that could affect the GPRS / EGPRS service CS traffic load PS traffic load Channel allocation and reservation User's mobility Figure 2 Other effects outside the BSS MS capability User's QoS profile BSS parameter setting Factors that Can Affect the GPRS/EGPRS User Perceived Performance Note: STS counters should not be used for benchmarking purposes between different vendors, the STS counters should only be used for evaluating and dimensioning the GPRS/EGPRS network. Note: If special traffic types such as EIT and DTM are excluded from the object types or counters it is explicitly stated. Otherwise all traffic types are included. 6.2 Level One - IP Data Volume and GPRS Availability 6.2.1 Introduction 6.2.1.1 IP Data Volume The five counters described here make it possible to measure the total data volume of all LLC data transferred in the cell, including GMM/SM signalling, and to calculate the percentage GMM/SM signalling. Strictly speaking IP data volume cannot be classified as a key performance indicator. But if performance problems are identified using other KPIs then the IP user data volume must be used to evaluate if these are worth fixing. However, in general if the performance of the network improves then the users will be able to transfer a greater volume of data within the same time. These other main uses for these counters are to: • Help decide if poor performance identified with other GPRS STS counters is worth fixing. • Indicate if there is enough statistical significance for the other GPRS STS counters to have meaningful values. • Identify possible downtime for the GPRS service together with the GPRS availability counters. All five counters include all types of transfers. 96 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Note: Strictly speaking what is actually measured inside the BSS is the data volume and throughput on the LLC layer (since the layers above LLC are transparent to the BSS). Therefore to be technically correct the LLC terminology is used in the description given below. However, an LLC-PDU is just one IP packet or one segment of a larger IP packet plus some LLC and SNDCP header data. There are only 11 bytes of header data in each LLC-PDU. So, for example, an IP packet of 1500 bytes was segmented into four LLC-PDUs of (3 * (489+11) bytes) + (1 * (33+11) bytes). The measured LLC throughput for this small transfer would then be only 2.33% higher than the actual IP throughput. max. ~1500 bytes "IP packet" max. ~500 bytes IP Packet Data Unit 7 bytes H SNDCP Payload 4 bytes H LLC Payload entire LLC-PDU = "LLC data" 37 bytes 20 bytes Example using CS-1 RLC H+C Payload 37 bytes 20 bytes H+C RLC Payload LLC-PDU packaged into RLC data blocks until entire LLC_PDU is sent RLC Payload = "RLC payload data" Figure 3 6.2.1.2 Transfer and Packing of Data between the Different Layers in the GPRS System. Counters for GPRS Availability The task of the GPRS availability measurement is to identify cells with no packet switched data transfer during the last 5 minutes, and therefore indicating a possible fault in the cell for Packet Switched traffic. If GPRS service is active and the downlink or uplink transferred data volume has been zero in the cell during the last 5 minutes an attempt is made to 216/1553-HSC 103 12/16 Uen E | 2010-11-10 97 User Description, Radio Network Statistics inject Packet Switched traffic in the cell. Traffic is injected by forcing a limited number of suspended GPRS attached MSs present in the cell to perform a “Routing Area Update”. If the number of traffic injection attempts over a period is non-zero, but the data transferred is still zero the cell is suspected to be unavailable for GPRS. Each injection is counted by the GPRSAVA counter. If at least 5 traffic injections have been made in a five minute interval without any data still being transferred in the cell, the counter GPRSCELLAVA is stepped once for every subsequent five-minute period until Packet Switched traffic is detected again in the cell. Note that new traffic injections will be continuously attempted in each five minute period until packet switched traffic is generated in the cell. 6.2.2 Object Types and Counters Object types: CELLGPRS3 Title: IP data volume counters per cell. DLSTRVOL Total LLC data volume transferred for all types of streaming (EIT) PFCs downlink. Units: kbit DLINTBGVOL Total LLC data volume transferred in interactive and background PFCs downlink. Units: kbit ULINTBGVOL Total LLC data volume transferred in interactive and background PFCs uplink. Units: kbit DLGMMVOL Total LLC data volume of GMM/SM signalling transferred downlink. Units: kbit ULGMMVOL Total LLC data volume of GMM/SM signalling transferred uplink. Units: kbit 98 GPRSAVA Total number of “traffic injections”, which are attempted in the cell every 5 minutes. GPRSCELLAVA Number of five-minute intervals the cell is suspected to be unavailable for GPRS. Will be incremented for each five-minute interval there is no Packet Switched traffic, after at least 5 traffic injections have been attempted within a five minute interval. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6.2.3 Suggested Formulae IP data volume is a measure of the traffic in the GPRS network. The following formula is one example of how to calculate the total IP data volume DL: IP volDL OL + DLIN T BGV OL 1 0 = DLST8RV3 1000 [M B=h] 3 P ERLEN 60 Equation 48 LLC Data Volume DL for the Whole Cell Including All Traffic Classes Except GMM/SM Signalling. Note that, B=byte=8 bits and; MB=megabyte=10^6 bytes. The following formula is one example of how to calculate the total IP data volume UL: IP volU L 0 P ERLEN 1 [M B=h] = 8 3 1000U3Lvol 60 : U Lvol = (V OLU LST RACC + LLC V OLU LEIT + DT M U LST RDAT A + U LIN T BGV OL) W here Equation 49 LLC Data Volume UL for the Whole Cell Including All Traffic Classes Except GMM/SM Signalling. Note that, B=byte=8 bits and; MB=megabyte=10^6 bytes. The following formula shows how to calculate the percentage of time a cell is suspected to be unavailable for GPRS: GP RSunavail Equation 50 A = 5 3 GPPRSCELLAV 3 100 [%] ERLEN Percentage of Time the Cell Is Suspected to Be Unavailable for GPRS. 6.3 Level One - IP Throughput 6.3.1 Introduction The objective with this set of counters is to allow the operator check the speed with which the BSS manages to transport IP packets to the users in each cell. There are similar counters for the BSC, described in Section 6.17.6 on page 173, but these are NOT suitable for measuring the IP throughput as perceived by the users ( the cell level counters must be accumulated over the BSC for this purpose). The BSC level counters should only be used to compare how resources are shared between different Traffic Classes and MBRs. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 99 User Description, Radio Network Statistics The IP throughput can be thought of as similar to the “modem speed” concept for fixed internet. A 56 kbps modem has the capacity to transmit 56 kbit of IP packets per second (but the end-user throughput will often be lower than this depending on the application used). A number of factors can affect the measured IP throughput, for example: • Poor radio link quality (level two counters — “Radio link quality”) • Less PDCH reserved than requested by the user (level two counters ”Multislot utilization”, “PDCH allocation”, “GSL device utilization” and “GPH RP load”) • Reserved PDCH shared by other users (level two counters “GPRS traffic load”) • QoS scheduling prioritizing another user (there are separate IP throughput counters for each QoS Traffic Class. Also level two counters — “GPRS traffic load” give the average QoS weight per PDCH). • Delays in setup of downlink TBFs, e.g. no allocated PDCHs or no CCCH capacity to send the assignment/channel request messages (included in the IP throughput counters). A very minor effect compared to those listed above. • MCPA overload Other factors that could affect the “modem speed” IP throughput but are not included in the measured IP throughput: • Discard of the contents of the IP buffer in the MS or in the PCU (level one counters — “IP buffer discard”, “IP transfer interrupts uplink” ). • Cell reselection during transfer. The IP throughput counters are on cell level. Therefore when the mobile moves between two cells the additional transfer time cannot be considered (the level one counter — “discards due to flush” and the level two counters — “Mobility” can be used to evaluate the impact of mobility on the users). • Delays in setup of uplink TBFs, e.g. no allocated PDCHs or no CCCH capacity to send the assignment/channel request messages (the PCU has no way of knowing when the MS first tried to setup the TBF). Additional factors that could affect the final end-user throughput (and are also not included in the measured IP throughput). • 100 The total time to perform a data transfer (the download of a web page for example) will include a number of TCP hand-shake procedures plus the transfers of the actual data content. The time waiting for these handshake messages to complete, basically a number of Round Trip Times, is not included in the IP throughput. These times are not limited by the throughput achieved in the BSS for these small IP packets. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring • Effects of protocol layers above the LLC layer (for example TCP slow start). Times in-between the transfer of IP packets in the BSS caused by higher level protocols are not measured in the BSS. • Events outside of the BSS that cause IP packets to be retransmitted by the TCP protocol. These are just seen as new IP packets by the BSS. The MS capability is another factor that can impact the measured IP throughput (in a rather complex way). Factors are: 6.3.2 • GPRS or EGPRS capable. • Multislot capability (level two counters— “Multislot utilization” can help). • Frequency band capability • 3GPP Release of the mobile (i.e. R4 mobile is capable of Network Assisted Cell Change and Extended UL TBF mode). Object Types and Counters Object type: CELLQOSG. Title: GPRS Quality of Service counters for cell, 24 counters. All these counters exclude DTM transfers or attempted transfers. “xy”GTHR Accumulated (LLC throughput * LLC data volume) for Basic and GPRS mode transfers where x=UL or DL and y=THP1 or THP2 or THP3 or BG. With Flexible Abis the counter values will be slightly lower. Units: kbit*kbit/s “xy”GDATA Accumulated LLC data volume for Basic and GPRS mode transfers where x= UL or DL and y=THP1 or THP2 or THP3 or BG. Units: kbit “xy”GPFC Accumulated number of Basic and GPRS mode data transfers or rather PFC activity periods where x=UL or DL and y=THP1 or THP2 or THP3 or BG. Units: integer Object type: CELLQOSEG. Title: EGPRS Quality of Service counters for cell, 24 counters. All these counters exclude DTM transfers or attempted transfers. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 101 User Description, Radio Network Statistics “xy”EGTHR Accumulation of (LLC throughput * LLC data volume) for EGPRS mode transfers where x=UL or DL and y=THP1 or THP2 or THP3 or BG. With Flexible Abis the counter values will be slightly lower. Units: kbit*kbit/s “xy”EGDATA Accumulated LLC data volume for EGPRS mode transfers where x= UL or DL and y=THP1 or THP2 or THP3 or BG. Units: kbit “xy”EGPFC Accumulated number of EGPRS mode data transfers or rather PFC activity periods where x=UL or DL and y=THP1 or THP2 or THP3 or BG. Units: integer Some examples of the full counter names: ULTHP3EGPFC Accumulated number of EGPRS mode data transfers or rather PFC activity periods for QoS class Interactive THP3 Units: integer ULTHP1GTHR Accumulation of (LLC throughput * LLC data volume) for all uplink GPRS mode transfers for QoS class Interactive THP1. Units: kbit*kbit/s DLBGGDATA Accumulated total LLC data received on the downlink in GPRS mode transfers for QoS class Background. Units: kbit Object type: CELLQOSS. Title: GPRS Quality of Service counters for streaming per cell, 17 counters. All these counters exclude contribution from TBFs carrying EIT. The counters also exclude DTM transfers or attempted transfers. 102 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring WTHR“xx”STRACC Accumulated (LLC throughput * LLC data volume) for all downlink streaming transfers where xx= requested GBR e.g. xx= 10 then the requested GBR was in the interval 10 to 19 kbps. With Flexible Abis the counter values will be slightly lower. Units: kbit*kbit/s VOL“xx”STRACC Accumulated LLC data volume for all downlink streaming transfers where xx= requested GBR e.g. xx= 10 then the requested GBR was in the interval 10 to 19 kbps. Units: kbit VOLULSTRACC Accumulated LLC data volume for all uplink TBF with Traffic Class = Streaming. Units: kbit Object type: CELLGPRS4. Title: Throughput based on MS GPRS or EGPRS capability, 8 counters. All these counters exclude DTM transfers or attempted transfers. The term GRPS and EGPRS here relates to the MS capability. DLMSGTHR Accumulation of (LLC throughput * LLC data volume) for GPRS capable MSs downlink, traffic classes background and interactive. Units: kbit*kbit/s DLMSEGTHR Accumulation of (LLC throughput * LLC data volume) for EGPRS capable MSs downlink, traffic classes background and interactive. Units: kbit*kbit/s ULMSGTHR Accumulation of (LLC throughput * LLC data volume) for GPRS capable MSs uplink, traffic classes background and interactive. Units: kbit*kbit/s ULMSEGTHR Accumulation of (LLC throughput * LLC data volume) for EGPRS capable MSs uplink, traffic classes background and interactive. Units: kbit*kbit/s 216/1553-HSC 103 12/16 Uen E | 2010-11-10 103 User Description, Radio Network Statistics DLMSEGDATA Accumulated LLC data volume for EGPRS capable MSs downlink, traffic classes background and interactive. Units: kbit DLMSGDATA Accumulated LLC data volume for GPRS capable MSs downlink, traffic classes background and interactive. Units: kbit ULMSEGDATA Accumulated LLC data volume for EGPRS capable MSs uplink, traffic classes background and interactive. Units: kbit ULMSGDATA Accumulated LLC data volume for GPRS capable MSs uplink, traffic classes background and interactive. Units: kbit Note: The throughput counters, xyGTHR, xyEGTHR and WTHRxxSTRACC, are affected by the interrupt that occur when PDCHs are up or downgraded due to Flexible Abis. Since an EGPRS mobile sometimes is reserved on one E-PDCH even if several B-PDCHs give better throughput, these counter values will not be comparable with the counter values received when Flexible Abis is not activated. This is because the mobile will not be able to receive the maximum number of PDCHs that it can handle, i.e. according to the multislot class and the number of E-PDCHs is limited. 6.3.3 Description Say that during a TBF there is a period of Packet Flow Context (PFC) activity with the following specific combination of characteristics: GPRS type = EGPRS; Direction = downlink; QoS class = THP1. See Reference [22] for more details on the terminology associated with the QoS feature. When the first LLC-PDU, for a period of activity for this PFC within the TBF, arrives in the PCU on the Gb interface, it triggers the start of an “active PFC lifetime” timer. The PCU will then attempt to start to segment the LLC-PDUs into RLC data blocks for transfer. After some time the flow of LLC-PDUs from the SGSN will stop. Eventually all the LLC-PDUs received on the Gb interface will have been successfully transferred to the MS as RLC data blocks. At this point the PCU buffer will have become empty. The “active PFC lifetime” timer is then stopped and the amount of LLC data sent in this individual period of PFC activity recorded. The basic principle is that the “active PFC lifetime” timer is always running in the PCU while there is user data to be sent to the MS.Note that even if the TBF is kept alive artificially by the system, with the feature “Delayed release of DL TBF” for example, the timer is still stopped since there is no user 104 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring data in the buffer. Also note that GMM/SM signalling is not included in these counters (it has a separate Traffic Class of its own). The time taken for the PCU to send a given amount of LLC data will depend on if and how often the system could schedule a transmission to the mobile, the coding scheme used for the transmitted RLC data blocks and the number of retransmissions of RLC data blocks required. LLC PDUs from SGSN TS TE Time Radio transmission Period of PFC activity (TE - TS) Figure 4 Example of a Period of PFC Activity for a Downlink Transfer During the same TBF the characteristics of the PFC could be changed or there may be other parallel active PFCs ongoing for the same user. However, at the end of each PFC activity period the following counters will be stepped: 1) The total amount of LLC data sent during the PFC activity period is calculated. This value is accumulated to the relevant "xy"GDATA, "xy"EGDATA or VOL"xy"STRACC counter. 2) For the period of PFC activity the LLC data volume is divided by the PFC activity lifetime to obtain the LLC throughput. This value is then weighted (multiplied) by the LLC data volume transferred in the period of PFC activity and accumulated to the relevant ; "xy"GTHR, "xy"EGTHR or WTHR"xy"STRACC counter. 3) The relevant "xy"GPFC or "xy"EGPFC counter is incremented by one. With the method outlined above, for each transfer the LLC data volume is used to weight the LLC throughput value (that will contribute to the overall average). This is because it is more important for the users that the IP throughput is optimized for long FTP transfers, for example, than for short WAP downloads. Also that the radio link quality (which impacts the IP throughput) should be optimized for the locations from where the majority of the data is being sent. However, by improving the IP throughput for large transfers we also improve the situation for small transfers. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 105 User Description, Radio Network Statistics The figure below shows how the counters work together with the “delayed release of downlink TBF” feature and what PFCs are included in the measurements. The shaded areas represent times when there is data in the downlink buffer for the PFC — a period of PFC activity (or one transfer). The weighted LLC throughput is calculated separately for each transfer. Example for one DL, GPRS mode TBF: DLTHP1GPFC incremented by 2, DLBGPFC incremented by1 = Contributes to xxPFC, xxTHR and xxDATA counters = Do not contribute to xxPFC, xxTHR and xxDATA counters Figure 5 Example of Stepping of Counters for One DL TBF with Several Transfers and Parallel Active Pfcs On the downlink it is possible for one user to have more than one active PFC in parallel during a single TBF. In that case, to maintain the throughput as a measurement of the BSS performance, only the PFC with the highest scheduling priority contributes to the accumulated LLC volume, number of PFCs and PFC activity time. PFCs with traffic class GMM/SM signalling have highest scheduling priority, however since they normally are very small they are not considered when excluding prallel PFCs. The reason for running parallel PFCs would typically be running an interactive PFC with application level signalling in parallel with a streaming PFC (e.g. for EIT). If there are two parallel PFCs with the same scheduling priority they are both excluded. For an uplink TBF the counters are handled in a similar way. However, the “active PFC lifetime” counter is started when the first RLC data block for the PFC arrives at the PCU to be assembled into an LLC-PDU. It is stopped either when the transfer ends or when the PFC is changed to another PFC during the same TBF. Note it is NOT possible for more than one active PFC to occur in parallel during a single TBF on the uplink. 106 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Note that if the QoS feature is switched off then the counters can still be used but all transfers are classified as Traffic Class “Background”. If a TBF is released abnormally (for example at cell reselection) then the counters are still stepped for that TBF but any partially sent/received LLC-PDUs are not considered. For the throughput counters in the object types CELLQOSG and CELLQOSEG the terms EGPRS and GPRS relate to the TBF mode. This shows the throughput for GPRS and EPGRS TBFs separately. In the object types CELLGPRS4 there is a subset of counters where the term GPRS and EGPRS relates to the capability of the MS. This is a better measure of the subscriber perception as an EPGRS capable MSs might be allocated a GPRS TBFs. The formulas for the counters in CELLGPRS4 are constructed the same way as for the counters in CELLQOSG and CELLQOSEG. 6.3.4 Suggested Formulae An example of the formula used to calculate the weighted average IP throughput for QoS classes Interactive and Background for Basic and GPRS mode TBFs is given below. Similar formulas can be constructed for EGPRS mode TBFs. P (ULT HPxGTHR) P (ULT HPxGDATA) [kbit=s] CQOSGthrINT BGul = ULBGGDAT A + x=[103] ULBGGT HR + x=[103] Equation 51 Weighted Average IP Throughput UL for Qos Classes Interactive and Background for GPRS. ULT HP 1GT HR [kbit=s] CQOSGthrTHP 1UL = ULT HP 1GDAT A Equation 52 Weighted Average IP Throughput UL per Data Transfer (Active PFC Is GPRS, Uplink, Qos Class = THP1) During the Measurement Period It is of course important to know the amount of IP data for which a certain IP throughput was achieved. For the above formula this is simply given by ULTHP1GDATA. Only the raw counter values are output from STS. The counters for streaming must NOT be used to evaluate the IP throughput performance of the cell.The IP throughput for these counters is determined by the GBRs requested by the users. They can be useful though to check that the actual average IP throughput provided is in-line with what was requested in the GBR. Note again though that this is the IP level throughput — when the DL PCU buffer becomes empty no IP throughput is measured. An example formula is given below. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 107 User Description, Radio Network Statistics HR10ST RACC [kbit=s] CQOSthrST R10 = WVTOL 10ST RACC Equation 53 Weighted Average IP Throughput per Data Transfer (Active PFC Is Downlink, Traffic Class = Streaming, Requested GBR in Range 10 to 19 kbps) During the Measurement Period 6.4 Level One - IP Latency 6.4.1 Introduction Each data session consists of a number of latency periods where the application server is waiting for a response from the user or vice versa. For example: • A user initiates the download of an e-mail from his server. A number of “handshake” exchanges must be completed before the download of the e-mail can begin. • At the very beginning of each data transfer TCP must receive an ACK message for the first IP packet sent before the next two IP packets are sent (TCP slow start). The length of each latency period is determined by how quickly the IP packet containing the “request” message can be sent through the system, processed by the receiver, and an IP packet containing the “response” sent back. These IP latency counters measure the delay Gb - BSS - MS - BSS - Gb. In the majority of GPRS networks the IP Latency measured in the described way contributes with more than 90% of the total client-server round-trip time. For applications such as WAP, where only short bursts of data are transferred, the IP latency is a major factor in determining the total time taken for each transfer. For applications like the download of a single large file the total transfer time is dominated by the IP throughput. The IP latency only has a very small impact (at the beginning of the transfer). For applications like web browsing (where one web-page contains a number of medium sized objects) there will be a number of latency periods and transfer periods. So both the IP throughput and IP latency are important in determining the total transfer time. Each application can be modeled as a number of latency periods and a number of transfer periods. The important thing to note is that by optimizing the measured IP throughput and the IP latency the user perceived performance is improved for all applications. 108 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6.4.2 Object Types and Counters Object type: CELLGPRS3. Title: IP Latency counters per cell. ACCEGEXTIPLAT Accumulated IP Latency measured for EGPRS capable and Extended UL capable but with no Reduced Latency capability MSs. Units: ms ACCEGNOEXTIPLAT Accumulated IP Latency measured for EGPRS capable and not Extended UL capable MSs. Units: ms ACCGEXTIPLAT Accumulated IP Latency measured for GPRS capable and Extended UL MSs. Units: ms ACCGNOEXTIPLAT Accumulated IP Latency measured for GPRS capable and not Extended UL capable MSs. Units: ms ACCEGRLIPLAT Accumulated IP Latency for an EGPRS capable MS with Reduced Latency capability (3GPP R7). Units: ms EGEXTIPLAT Number of accumulations of IP latency for all valid samples for EGPRS capable and Extended UL capable but with no Reduced Latency capability MSs. EGNOEXTIPLAT Number of accumulations of IP latency for all valid samples for EGPRS capable and not Extended UL capable MSs. GEXTIPLAT Number of accumulations of IP latency for all valid samples for GPRS capable and Extended UL MSs. GNOEXTIPLAT Number of accumulations of IP latency for all valid samples for GPRS capable and not Extended UL capable MSs. EGRLIPLAT Number of accumulations of IP latency measurements for an EGPRS Reduced Latency capable MS (3GPP R7). 216/1553-HSC 103 12/16 Uen E | 2010-11-10 109 User Description, Radio Network Statistics 6.4.3 Description It is impossible to measure in the BSC the IP Latency from the perspective of the MS (like a “ping” measurement) since the PCU never knows when the MS first tries to access the system ( the first attempt could be lost over the air-interface). Instead the IP latency is measured in the reversed direction. For every small IP packet received on the Gb interface into an empty downlink management buffer in the PCU a timer is started. Normally a small IP packet will be received on the uplink in response. If so, the timer is stopped when this “response” IP packet is sent out from the uplink management buffer onto the Gb interface. This is a valid sample of the IP latency. MS PCU SGSN Gb "Request" IP packet BSC IP Latency "Response" IP packet Figure 6 Note: Measure of IP Latency. The time from the MS receiving the “request” IP packet until the “response” IP packet is sent from the MS is also included in the measure. The PCU only deals in LLC PDUs and is not aware of what an IP packet is, but we can assume that a small, isolated LLC PDU received in the PCU to an empty DL buffer is indeed a “request” IP packet. To ensure this and to minimize the impact from the size of the IP packet ( a large IP packet will have a larger transmission time) only very small packets contribute to the IP latency measure. Therefore there is an upper limit on the size of LLC PDUs that contributes to the IP Latency measure. If either the downlink or uplink LLC PDU exceeds these sizes then the IP latency sample is considered invalid and the counters will not be stepped. The internal parameter IPLATTIME gives the maximum time an IP Latency measurement is reported for. If the IP latency sample exceeds this value it is considered invalid and the counters will not be stepped. 110 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring The IP Latency measured as described will be dependent on a number of factors: • The processing delays in the PCU. • The processing delays in the MS. • If an uplink TBF needs to be setup using the RACH and PRACH. This is extremely unlikely since the new uplink TBF can usually be requested using the PACCH of the downlink TBF (which is being kept alive with the feature Delayed release of DL TBF). • If the MS is compliant with 3GPP R4 and therefore capable of “Extended UL TBF”. If the session was initiated by a request from the MS for an uplink TBF then this TBF can be reused, no new uplink TBF needs to be requested. • How quickly the MS was scheduled with a USF on the uplink. The parameter settings for the feature Persistent UL Scheduling and if the MS is 3GPP R4 compliant will have a large impact. The USF scheduling will take longer if many users are sharing the same PDCH. Furthermore, If there is a large amount of Reduced Latency Capable terminals (3GPP R7) and the associated BSS feature is active in the network the EGPRS latency will be lowered. • The transmission times for the DL and UL IP packets i.e. the radio link quality and coding schemes used. Even though the IP packet size is limited (usually to around 80 bytes) there may still be a small impact. The counters are split so that samples for mobiles that are capable of Extended UL TBF mode are collected separately from those that are not. The counters are also split so that samples for mobiles that are capable of EGPRS are collected separately from those that are not. The latency in BSS will differ depending on when in a session the IP latency is measured. There are two different IP latencies that can be measured: • Out of session latency – latency for transfers that are not within a session (i.e. no DL TBF is set-up). • In session latency – latency for transfers that are within a session (i.e. DL TBFs are already set-up). In session latency The KPI for BSS IP latency measures the in session latency. For end-users running TCP/IP applications (which are predominant in the networks today) it is the in session latency that is important while the out of session latency impacts the end-user performance only marginally. Out of session latency 216/1553-HSC 103 12/16 Uen E | 2010-11-10 111 User Description, Radio Network Statistics The out of session latency (measured e.g. by the first ping in a ping series) corresponds to the first access after a period of end-use idleness. The out of session latency is important only for a very limited set of applications. The out of session latency (first Ping) will be consistently longer than the in session latency (consecutive Pings). This is because the time for the first ping includes setup times for one UL and one DL TBF (which takes 300–500 ms in total). In contrast the following Pings in the series use already established UL TBFs. If two-phase access is used for EDGE, the first ping takes ~200 ms longer time for EDGE than for GPRS while the latency for the following pings is equal for GPRS and EDGE. The out of session latency is not measured by counters in BSS. 6.4.4 Suggested Formulae The following formula, IPLAT_TOT, shows the total average GPRS and EGPRS IP Latency including Reduced Latency capable (3GPP R7) Mobiles. JP LAT tot = GP RSlat + EGP RSlat [ms] SamplesGP RS + SamplesEGP RS W here : GP RSlat = ACCGNOEXT IP LAT + ACCEGNOEXT IP LAT EGP RSlat = ACCGEXT IP LAT + ACCEGEXT IP LAT + ACCEGRLIP LAT SamplesGP RS = GNOEXT IP LAT + EGNOEXT IP LAT SamplesEGP RS = GEXT IP LAT + EGEXT IP LAT + EGRLIP LAT Equation 54 Total average IP Latency for GPRS and EGPRS terminals, including Reduced Latency capable (3GPP R7) Mobiles. ' And this formula, IPLAT_GNO, shows the average IP Latency for GPRS capable only mobiles that are not capable of Extended UL TBF. IP LAT gno = Equation 55 112 ACCGNOEXT IP LAT [ms] GNOEXT IP LAT Average IP Latency for GPRS Capable Only Mobiles that Are Not Capable of Extended UL TBF. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6.5 Level One - IP Transfer Interrupts Downlink (IP Buffer Discards) 6.5.1 Introduction The IP throughput counters measure the speed with which the BSS ships IP packets to and from the users. But what happens when the BSS has received IP packets from the SGSN but cannot transfer these to the MS for some reason (perhaps the BSS could not setup a connection to the MS or the connection was broken mid-transfer)? Then the entire contents of the buffer in the PCU and SGSN will be discarded. Even if, as is likely in most cases, the data transfer is automatically reestablished fairly quickly by the higher layer protocols (TCP or UDP), there will still be some impact on the transfer of IP packets from the discard. For TCP transfers this will usually result in a temporary reduction in the send rate of the TCP connection (TCP congestion avoidance and/or slow start). For UDP transfers the application may request re-sending of the discarded data. The user experience of an IP buffer discard is heavily dependent on the application he/she is running. But there will be some interruption in the transfer since the buffer is empty after the discard. It is the number of these interruptions in service that are important to measure rather than the amount data discarded. With the feature Loss Free Preemption, the downlink buffer will be kept for 10 seconds when a TBF has been interrupted or is delayed during setup, (then the entire content of the buffer will be discarded). During that 10 seconds attempts will be made to setup a new TBF in the cell. And if that succeeds no data is lost and the impact to the end user is minor. The contents of the PCU buffer may also be discarded due to an inter Routing Area or inter PCU cell reselection and a counter is included to monitor these. However, these are impossible to optimize completely to zero in any system. 6.5.2 Object Types and Counters Object type: CELLGPRS2. Title: IP buffer discard counters per cell (subset of all counters in object type). All these counters exclude DTM transfers or attempted transfers. LDISTFI 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Number of times the entire contents of a downlink buffer in the PCU were discarded due to the reason no available PDCH or TFI. This can be at TBF setup or at TBF release due to preemption. Note that this counter only relates to lack of resources over the air interface. Allowing more basic physical channels to be allocated 113 User Description, Radio Network Statistics as PDCH will generally have a positive effect on this counter. The number of TFIs is limited to 32 per PSET and the parameters DLDELAY, ESDELAY and TFILIMT may also have an effect and are described in Reference [21]. GMM/SM signalling is not included in the counts. Units: integer LDISRR The counter LDISRR counts the total number of times, per cell, that the entire content of the downlink LLC PDU buffer was discarded due to radio reasons (GMM/SM signalling is not included in the counts.): • TBF cannot be setup due to no answer from MS • TBF released due to lost contact with the MS Note: for cells at BSC boundaries it could be possible for this counter to step due to long outage times for cell reselection between PCUs (i.e. radio contact could be lost and the buffer discarded before the Flush message is received from the SGSN). If packet Abis are used for transmission and there is an overload situation resulting in that there are interrupts persisting for longer times, TBFs will be lost. This will be visible in counters LDISRR, LDISRRSUB, IAULREL and IAULRELSUB and also in an increased total frame/packet loss ratio on the packet Abis interface (Section 7.1 Frame Loss Ratio Formulas for Packet Abis on page 191). Units: integer Object type: CELLGPRS. Title: TBF establishment counters downlink per cell (subset of all counters in object type). All these counters exclude DTM transfers or attempted transfers. 114 LDISEST The counter LDISEST counts the number of times the entire content of the downlink LLC PDU buffer was discarded during downlink TBF establishment regardless of reason. GMM/SM signalling is not included in the counts. MSESTDLTBF The counter MSESTDLTBF counts the number of successfully established DL TBFs where at least one data block has been sent and acknowledged. LDISOTH Number of times the entire contents of a downlink buffer in the PCU were discarded for any other reason than 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring those listed here. GMM/SM signalling is not included in the counts. Units: integer FLUDISC Number of times the entire contents of a downlink buffer in the PCU were discarded due to an inter RA cell reselection or inter PCU cell reselection (i.e. a Flush message was received in PCU to delete the contents of a PCU buffer). Units: integer Object type: CELLGPRSO. Title: IP buffer discards in the overlaid subcell, 1 counter (subset of all counters in object type). LDISRRSUB The counter LDISRRSUB counts the total number of times, per overlaid subcell, that the entire content of the downlink LLC PDU buffer was discarded due to radio reasons (GMM/SM signalling is not included in the counts.): • TBF cannot be setup due to no answer from MS • TBF released due to lost contact with the MS • TBF released due to exceeded border for overlaid subcell, while not possible to reserve in underlaid subcell. Note that this is only applicable in combined normal and extended range cells. Note: for cells at BSC boundaries it could be possible for this counter to step due to long outage times for cell reselection between PCUs (i.e. radio contact could be lost and the buffer discarded before the Flush message is received from the SGSN). If packet Abis are used for transmission and there is an overload situation resulting in that there are interrupts persisting for longer times, TBFs will be lost. This will be visible in counters LDISRR, LDISRRSUB, IAULREL and IAULRELSUB and also in an increased total frame/packet loss ratio on the packet Abis interface (Section 7.1 Frame Loss Ratio Formulas for Packet Abis on page 191). Units: integer 216/1553-HSC 103 12/16 Uen E | 2010-11-10 115 User Description, Radio Network Statistics 6.5.3 Description The downlink buffer in the PCU actually contains LLC-PDUs. However a discard of at least one LLC-PDU is the same thing as a discard of at least one IP packet. Therefore the counters are called “IP buffer discards”. One of the counters is stepped whenever the decision is taken to discard the entire contents of the downlink PCU buffer. There is one condition — the counters are not stepped if the PCU buffer was empty when the decision was taken, since such a “discard” will not have any affect on the TCP or UDP protocols. Also a PCU buffer that contains only GMM/SM signalling LLC-PDUs is considered to be an empty buffer. 6.5.4 Suggested Formulae The absolute number of IP buffer discards is a relevant performance indicator. This shows the number of times that the BSS had to discard IP packets and therefore the higher layer protocols for a users data transfer were affected. For a relative comparison of performance between different cells it is suggested to calculate the number of IP buffer discards per data transfer session minutes (estimated with the number of downlink TBF minutes). P SipdisCLM = Equation 56 (T BFDLGPRS + T BF DLEGP RS ) =6 [mins] LDIST F I + LDISRR + LDISOT H + F LUDISC Average Downlink Data Session Transfer Minutes per Downlink IP Buffer Discard In order to calculate the percentage of TBF establishment attempts where the downlink LLC PDU buffer was discarded during the TBF establishment phase the following formula can be used: DIStbf = 100 3 Equation 57 LDISEST [%] LDISEST + MSEST DLT BF Percentage of TBF establishment attempts where the downlink LLC PDU buffer was discarded during the TBF establishment phase 6.6 Level One - IP Transfer Interrupts Uplink (MS to BSS Connection Issues) 6.6.1 Introduction Ideally there should be a mirror image of the IP buffer discard counters for the uplink. However it is impossible for the PCU to know when the MS has decided to discard the contents of its IP buffer. 116 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Instead we measure the number of times the PCU knew the MS had data to send but was unable to for some reason. These can be split into two areas: 6.6.2 • MS Access Rejects (MS request to setup an uplink TBF must be repeated) • MS to BSS connection loss (Ongoing uplink TBF released with countdown value not 0) Object Types and Counters Object types: CELLGPRS2 and CELLGPRS3. Title: MS to BSS connection issues per cell (subset of all counters in object type). All these counters exclude DTM transfers or attempted transfers. Object type: CELLGPRS2 PSCHREQ Number of packet access requests in the cell received in the PCU on any channel: RACH, PRACH or PACCH (in Packet Downlink Ack/Nack). A packet access request is normally to setup an uplink TBF. Units: integer PREJTFI Number of rejected packet access requests for the reason “no PDCH, no USF or no TFI”. Request is rejected by sending either “Immediate Assignment Reject” message or “Packet Access Reject” message. Increasing the number of basic physical channels that can be allocated as PDCH will generally have a positive effect on this counter. The parameters ULDELAY, USFLIMIT and TFILIMIT may also have an effect and are described in Reference [21]. Units: integer PREJOTH Number of rejected access requests for any other reason than “no PDCH, no USF or no TFI” and packet Abis overload. Request is rejected by sending either “Immediate Assignment Reject” message or “Packet Access Reject” message. Note that PREJOTH also include Packet Access Requests rejected due to GPH Load Control mechanism, that is, the rejects that are separately counted by LCLRPARREJ and LCPARREJ. Units: integer IAULREL 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Number of times an already established uplink TBF has been closed down because radio contact has been 117 User Description, Radio Network Statistics lost with the mobile. The counter is only stepped if there is an ongoing transfer i.e. the MS have sent at least one RLC block in the TBF and not yet reached CV=0. Note: on the uplink it is impossible for the BSS to differentiate between radio contact lost due to bad radio conditions or release due to DTM setup. This counter will sometimes step for TBFs abnormally released due to DTM setup from packet transfer mode. In terms of Cell Reselections, the counter CRSULREL has been introduced in 06B to count the number of uplink TBFs released due to cell reselections . Cell reselections were previously included in IAULREL. Hence, the value of IAULREL will decrease compared to previous releases. If packet Abis are used for transmission and there is an overload situation resulting in that there are interrupts persisting for longer times, TBFs will be lost. This will be visible in counters LDISRR, LDISRRSUB, IAULREL and IAULRELSUB and also in an increased total frame/packet loss ratio on the packet Abis interface (Section 7.1 Frame Loss Ratio Formulas for Packet Abis on page 191). Units: integer CRSULREL The total number of times, per cell, that an established uplink TBF was released due to a successful cell reselection. Units: integer PREEMPTULREL Total number of UL TBFs abnormally released due to preemption (either due to CS channel congestion, Abis congestion (for CS only) or VGCS). The counter is only stepped if there is an established uplink TBF. The impact on the user (i.e. interruption in service) is likely to be smaller than when a TBF is released due to lost radio contact. OTHULREL Total number of UL TBFs abnormally released due to all other reasons than preemption, cell reselections or radio contact lost. The counter is only stepped if there is an established uplink TBF. The impact on the user (i.e. interruption in service) is likely to be smaller than when a TBF is released due to lost radio contact. The most common reason for OTHULREL is that the handling of a cell is moved to another RP. MSESTULTBF Number established uplink TBFs were the MS has started to send data (at least one RLC block received). Units: integer 118 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Object type: CELLGPRS3 PREJABISCONG Number of UL Temporary Block Flows (TBFs) for new MSs (not in DTM) that have been rejected on PDCH:s carried on traffic session that have Abis congestion, for Packet Abis. Object type: CELLGPRSO. Title: Counters for GPRS in the overlaid subcell (subset of all counters in object type). IAULRELSUB Number of times an uplink TBF has been closed down because radio contact has been lost with the mobile in the overlaid subcell only. The counter is only stepped if there is an ongoing transfer i.e. the MS have sent at least one RLC block in the TBF and not yet reached CV=0. The radio conditions in the overlaid subcell could be very different to those in the whole cell (overlaid and underlaid subcell together). Note: In 06B The counter CRSULRELSUB has been introduced to count the number of uplink TBFs released due to cell reselections. Cell reselections were previously included in IAULRELSUB. Hence, the value of IAULRELSUB will decrease compared to previous releases. If packet Abis are used for transmission and there is an overload situation resulting in that there are interrupts persisting for longer times, TBFs will be lost. This will be visible in counters LDISRR, LDISRRSUB, IAULREL and IAULRELSUB (if there is a contact to MS) and also in an increased total frame/packet loss ratio on the packet Abis interface (Section 7.1 Frame Loss Ratio Formulas for Packet Abis on page 191). Units: integer CRSULRELSUB The total number of times, per overlaid subcell, that an established uplink TBF was released due to a successful cell reselection. Units: integer 6.6.3 Description A rejected packet access means that the MS has to retry its attempt to access the system. Normally the MS is prevented from attempting packet accesses in the same cell until the Wait Indication has expired (T3412 specified in the Immediate Assignment Reject message or T3172 (optional) specified in the Packet Access Reject message). This value always 5 seconds in the Ericsson BSS. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 119 User Description, Radio Network Statistics A rejected packet access does not directly relate to a failure to transfer IP packets on the uplink since a packet access procedure is still required for other purposes (for example for the transfer of GMM/SM signalling). However the ratio of rejected packet access will give a good indication if there are problems in the cell. There are some situations where the MS will be forced to repeat an attempt to access the system. For all cases though the access attempt will be repeated almost immediately, hence the negetive impact on the user perception of the service is likely to be small. Case two and three below can be calculated by subtracting the number of access rejects (PREJOTH and PREJTFI and PREJABISCONG) and established uplink TBFs (MSESTULTBF) from the total number of access requests (PSCHREQ). • The first case is when the packet access attempt message gets lost or is corrupted over the air interface. However, only the packet access attempts that successfully reach the BSS can ever be counted in the BSS. • The second case is when the Access Grant Channel (on CCCH) or Packet Access Grant Channel (on PCCCH) is completely congested over the air-interface and assignment messages are discarded in the BTS. However, this situation is unlikely to arise since Immediate Assignment messages have priority over pages in the CCCH queue and its capacity (number of Immediate Assignment messages per second) is extremely high. The congestion situation on CCCH can be checked using the counters in object type CELLPAG and using the process described in the Location Area Dimensioning Guideline. Finally if there is a real congestion problem on the CCCH in a cell there is also likely to be real congestion problems on the traffic channels in the cell. • The third case is if the TBF setup procedure fails for other reason, and the PCU cannot send the assignment or the assignment does not reach the MS, for example if a DL TBF is terminated before an assignment can be sent on PACCH or if the assignment gets lost over the air interface. When the MS to BSS connection is lost due to radio reasons, again, this does not indicate a direct impact on the users in terms of a failure to transfer IP packets on the uplink, but does gives an indication that there may be coverage and/or interference problems in the cell. Again though it should be noted that it is impossible for the BSS to distinguish between radio contact lost due to cell reselection (non-NACC) and other radio reasons on the uplink. It is the MS that makes the decision to leave the old cell without the involvement of the BSS. 6.6.4 Suggested Formulae The average UL data session transfer in minutes per abnormally released TBF UL and access rejects. A combined user integrity measure for mobility, TBF retainability and TBF accessibility (assuming the delay or interruption to the user transfer is similar in all cases). 120 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring PSulrelCLM = (T BFULGPRS + T BF ULEGP RS ) =6 [mins] RejUl + RejUlResource W here : RejUlRR = IAUREL + CRSULREL + OT HULREL RejUlResource = P REJT F I + P REJOT H + P REEMP T ULREL + P REJABISCONG Equation 58 Average UL Data Session Transfer in Minutes per Abnormally Released TBF UL and Access Rejects It is recommended to calculate the percentage of packet access requests that were rejected compared to the total number of requests. P Sparr = P REJT F I + P REJOT H + P REJABISCONG 3 100 [%] P SCHREQ Equation 59 6.7 Percentage of All Packet Access Requests that Were Rejected GPRS user session counters for active users In order to have a measure for active users in the system which is independent of the implementation of the TBFs there is a special set of counters allowing measurements of the session time for active users (mobiles) in the system. This is a valuable measure as an indication of the traffic in the system (comparable to Erlang in the CS domain) and can also be used to normalize other counters into formulas or KPIs, e.g. number of lost TBFs per session minute. The counters in this section count the number of active users (MSs) of GPRS and EGPRS, in non-DTM and DTM mode, respectively. This is done by scanning the number of active MSs every tenth second. An MS is regarded as active if there is an ongoing data transfer uplink or downlink, or if there has been a data transfer uplink or downlink during the last second. GMM/SM signaling and PCU induced traffic (due to “Delayed Release of Downlink TBF” mode, “Extended Uplink” mode or “Early Setup of Downlink TBF” mode) is, in this matter, not regarded as active use. For non-DTM transfers the following counters are introduced: ACTGUSE The accumulated number of active users with GPRS capable mobiles. DTM is not included. Units: number of users ACTEUSE The accumulated number of active users with EGPRS capable mobiles. DTM is not included. Units: number of users 216/1553-HSC 103 12/16 Uen E | 2010-11-10 121 User Description, Radio Network Statistics ACTUSESCAN The counter ACTUSESCAN is incremented by one every time the number of active users is scanned. DTM is not included. Units: number of scans For DTM transfers the following counters are introduced: DTMACTGUSE The accumulated number of active users with GPRS capable mobiles in DTM. Units: number of users DTMACTEUSE The accumulated number of active users with EGPRS capable mobiles in DTM. Units: number of users DTMACTUSESCAN The counter ACTUSESCAN is incremented by one every time the number of active users in DTM is scanned. Units: number of scans 6.8 Level One - Streaming Connection Negotiations 6.8.1 Introduction At the initiation of a downlink streaming transfer an attempt is made by the system to reserve a number of PDCH on which the streaming transfer will have absolute priority — “Effective streaming PDCH”. This request is always done in accordance with the “requested GBR” that is stored in the ABQP. See Reference [22] for more details. By monitoring the outcome of these attempts to reserve resources it can be seen if the users get the GBR, and hence the quality of service, they requested. The importance of the parameters BPDCHBR, GPDCHBR, EPDCHBR in matching the number of “Effective streaming PDCH” to the actual bit rate received by the user should be kept in mind. These parameters can be set with the help of the radio link bit rate counters described in Section 6.9 on page 124. Note that the measured radio link bit rates are on RLC level while the parameters are set on LLC level (i.e. the additional overhead for LLC described in the referenced chapter should be considered when setting these parameters). The number of preemptions of on-demand PDCH that were effective streaming PDCH are also counted to keep track of degradations in service after the PDCH have been reserved. 122 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6.8.2 Object Types and Counters Object types: CLQOSSCON and CLQOSSCON2 Title: Streaming connection negotiation counters, 28 counters per cell in total for both object types. All these counters exclude contribution from TBFs carrying EIT. GBR10REQ Accumulated number of streaming TBFs that have been reserved on the required number of “Effective Streaming PDCH” in the requested GBR interval 10–19. Similar counters for GBR ranges 20–29, 30–39, 40–59, 60–79, 80–119, 120–159, 160 and over. Units: integer GBR10LOW Accumulated number of streaming TBFs that have been reserved on fewer “Effective Streaming PDCH” than required in the requested GBR interval 10–19. Similar counters for GBR ranges 20–29, 30–39, 40–59, 60–79, 80–119, 120–159, 160 and over. With Flexible Abis the counter values will be slightly higher. Units: integer GBR10FAIL The accumulated number of streaming TBFs that have failed to reserve any “Effective Streaming PDCH” for exclusive use for streaming (due to resource shortage or unavailability of support) and hence have been reserved in accordance with the QOSSTREAMPRIO parameter in the requested GBR interval 10–19. Similar counters for GBR ranges 20–29, 30–39, 40–59, 60–79, 80–119, 120–159, 160 and over. With Flexible Abis the counter values will be slightly higher. Units: integer CELLPPRS Accumulated number of “Effective Streaming PDCH” that were preempted. TBFUPS Number of times a streaming TBF has been successfully upgraded. With Flexible Abis the counter values will be slightly lower. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 123 User Description, Radio Network Statistics 6.8.3 Suggested Formulae It is suggested to construct formulas for the fraction of the total requests that resulted in 1) the required number of PDCH being reserved 2) less PDCH than the required number being reserved 3) failures. Per GBR interval and then also for the requests for all GBR intervals combined. A measure of the systems ability to provide the GBR, and hence the quality of service, the users requested. The following formula gives the percentage of QoS negotiations resulting in the requested GBR. “xx” relates to the GBR intervals the counters are divided in. Sum (GBRxxREQ) QOSneg = Sum (GBRxxLOW ) + Sum (GBRxxFAIL) + Sum (GBRxxREQ) 3 100 [%] Equation 60 Note: Percentage of Qos Negotiations Resulting in the Requested GBR. The success rate will vary with the type of streaming traffic in the cell (higher requested GBRs are more difficult to serve). 6.9 Level Two - Radio Link Quality 6.9.1 Introduction The quality of each users radio link determines the maximum the IP throughput they can achieve. The counters described here are used to measure the radio link bit rate per PDCH. If each PDCH is thought of as a “pipe” through which data can be transferred then the measured radio link bit rate represents the average size of each pipe. There are many different influences on the quality of a radio link: signal strength; interference; time dispersion and more. However, it is important to understand that for GPRS/EGPRS of all these aspects combine to give a certain bit rate that the radio link can support, and this is the only thing that matters to the end-user. A radio link that can support 12 kbps per PDCH is always 50% more useful to the end-user than a radio link that supports only 8 kbps per PDCH. Therefore all radio-related optimization and parameter setting should aim to maximize the bit rate of the radio channels, which will in-turn improve the IP throughput. The concept of counters to measure the Block Error Rate (BLER) has been used in previous releases to measure the radio link quality which, with fixed coding schemes, was an indirect way to measure the radio link bit rate. However, with the features Link Adaptation and Link Quality Control this concept is no longer valid. Instead the radio link bit rate is measured directly. The maximum number of radio blocks that can be transferred over the air interface is 50 per second. So the channel time used to send 1 RLC data block is 20 ms. By measuring the volume of RLC data that could be sent within a certain channel time (number of RLC data blocks * 20 ms) we obtain a value for 124 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring the radio link bit rate per PDCH. It does not matter if the data sent on the PDCH came from one user or if the PDCH is shared by many users. The perfect radio link quality is represented by: • Close to 12 kbps per PDCH for CS-1/2 transfers (on B-PDCH, G-PDCH or E-PDCH). • Close to 20 kbps per PDCH for CS-1/2/3/4 transfers (on G-PDCH or E-PDCH). • Close to 59 kbps per PDCH for EGPRS transfers (on E-PDCH). Of course the “perfect” radio link quality for CS-1/2/3/4 and EGPRS transfers needs to be of much better quality than the “perfect” radio link quality required for CS-1/2 transfers. For example if a transfer uses CS-2 then different counters must be stepped depending on which TBF mode is used. When CS-2 is used during a CS-1/2/3/4 mode TBF it results in a radio link bitrate of, at best, 12 kbit/s which indicates a problem with radio link quality for this transfer. When CS-2 is used for a CS-1/2 mode TBF the best possible radio link bitrate is still only 12 kbit/s but this does not indicate a problem with the radio link quality for this transfer.Therefore the radio link bit rate must be measured with completely separate counters for CS–1/2, CS–1/2/3/4 and EGPRS data transfers. Counters are provided that allow the following to be calculated: 6.9.2 • Average radio link bit rate and RLC data volume in the whole cell (underlaid subcell plus overlaid subcell) for all uplink and for downlink CS-1/2 transfers. There are counters that count the number of RLC/MAC data blocks scheduled for the transmission of user data and GMM/SM signaling (the xSCHED counters), this allows the used channel time to be calculated (each radio block occupies 20 ms). There are also counters showing the volume of user data and GMM/SM signaling data (the xACK counters). Object type CELLGPRS. • Distributions of the radio link bit rate versus RLC data volume in the whole cell (underlaid subcell plus overlaid subcell) for downlink CS-1/2/3/4 and downlink EGPRS transfers. These are interval counters (the INTx counters ) that count the downlink RLC data volume in certain bitrate intervals, allowing a distribution of the radio link bitrate to be presented. This gives an excellent picture of the distribution of the radio link quality in the cell. Object type RLINKBTR. • Average radio link bit rate and RLC data volume separately for all types of transfers in the overlaid subcell, these are similar to the counters in CELLGPRS. Object type CELLGPRSO. Object Types and Counters Object types: CELLGPRS, CELLGPRS2 and CELLGPRSO. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 125 User Description, Radio Network Statistics Title: Radio link bit rate counters per cell for all DL and UL transfers, 8 counters per cell (subset of all counters in object type) in the whole cell (underlaid + overlaid subcells). Radio link bit rate counters for all transfers in the overlaid subcell, 10 counters per overlaid subcell (subset of all counters in the object type). These counters are stepped also for abnormally released TBFs up until the last correctly received block. Note: To get an accurate measure of the radio link quality the counters for RLC data on the uplink (the xACK counters) are under some conditions also stepped for repeated radio blocks, see Section 6.9.3 on page 130. CS12DLSCHED Total number of DL RLC data blocks scheduled by PCU for the transmission of user data or GMM/SM signalling in CS-1/2, RLC acknowledged mode TBFs. Retransmissions are included. RLC/MAC signalling blocks and RLC dummy blocks are excluded. CS12DLSCHEDSUB is the counter for transfers in the overlaid subcell. Units: Integer (number of blocks) CS12DLACK Counts the total amount of RLC data successfully received in the MSs for CS-1/2, RLC acknowledged mode TBFs. CS12DLACKSUB is the counter for transfers in the overlaid subcell. Units: bits CS12ULSCHED Total number of RLC data blocks scheduled by MSs for the transmission of user data or GMM/SM signalling in CS-1/2, RLC acknowledged mode TBFs. Retransmissions are included. RLC/MAC signalling blocks and RLC dummy blocks are excluded. CS12ULSCHEDSUB is the counter for transfers in the overlaid subcell. Units: Integer (number of blocks) CS12ULACK Counts the total amount of RLC data successfully received in the PCU for CS-1/2, RLC acknowledged mode TBFs. CS12ULACKSUB is the counter for transfers in the overlaid subcell. Units: bits CS14DLSCHED 126 Total number of DL RLC data blocks scheduled by PCU for the transmission of user data or GMM/SM signalling in CS-1/2/3/4, RLC acknowledged mode TBFs. Retransmissions are included. RLC/MAC signalling blocks and RLC dummy blocks are excluded. CS14DLSCHEDSUB is the counter for transfers in the overlaid subcell. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Units: Integer (number of blocks) CS14DLACK Total amount of RLC data volume successfully acknowledged by MSs with a GPRS mode TBF (CS-1 to CS-4) in RLC acknowledged mode, downlink. Units: bits CS14DLACKSUB Counts the total amount of RLC data sent on the DL successfully received by the MSs in the overlaid subcell for CS-1/2/3/4, RLC acknowledged mode TBFs. Units: bits MC19DLSCHED Total number of 20 ms periods of channel time (1 or 2 RLC data blocks) scheduled by PCU for the transmission of user data or GM/SMM signalling in EGPRS, RLC acknowledged mode TBFs. Retransmissions are included. RLC/MAC signalling blocks and RLC dummy blocks are excluded. MC19DLSCHEDSUB is the counter for transfers in the overlaid subcell. Units: Integer (number of blocks) MC19DLACK Total amount of RLC data volume successfully acknowledged by MSs with a EGPRS mode TBF (MCS-1 to MCS-9) in RLC acknowledged mode, downlink. Units: bits MC19DLACKSUB Counts the total amount of RLC data sent on the DL successfully received by the MSs in the overlaid subcell for EGPRS, RLC acknowledged mode TBFs. Units: bits MC19ULSCHED Total number of 20 ms periods of channel time (1 or 2 RLC data blocks) scheduled by MSs for the transmission of user data or GM/SMM signalling in EGPRS, RLC acknowledged mode TBFs. Retransmissions are included. RLC/MAC signalling blocks and RLC dummy blocks are excluded. MC19ULSCHEDSUB is the counter for transfers in the overlaid subcell. Units: Integer (number of blocks) MC19ULACK 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Counts the total amount of RLC data successfully received by the PCU for EGPRS, RLC acknowledged mode TBFs. MC19ULACKSUB is the counter for transfers in the overlaid subcell. 127 User Description, Radio Network Statistics Units: bits Object type: RLINKBITR. Title: Radio link quality counters per cell for downlink CS-1/2/3/4 and EGPRS mode transfers. All these counters exclude contribution from TBFs carrying EIT. The counters are only stepped for normally released TBFs. All units are (kbit). INT8BRGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 8 kbps (X < 9 ) interval for CS-1/2/3/4, RLC acknowledged mode TBFs. Unit: kbit INT10BRGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 10 kbps interval (9 <= X < 11) for CS-1/2/3/4, RLC acknowledged mode TBFs. Unit: kbit INT12BRGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 12 kbps interval (11 <= X < 13) for CS-1/2/3/4, RLC acknowledged mode TBFs. Unit: kbit INT14BRGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 14 kbps interval (13 <= X < 15) for CS-1/2/3/4, RLC acknowledged mode TBFs. Unit: kbit INT16BRGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 16 kbps interval (15 <= X < 17) for CS-1/2/3/4, RLC acknowledged mode TBFs. Unit: kbit 128 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring INT18BRGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 18 kbps interval (X=> 17) for CS-1/2/3/4, RLC acknowledged mode TBFs. Unit: kbit INT10BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 10 kbps interval (X < 12.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit INT15BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 15 kbps interval (12.5 <= X < 17.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit INT20BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 20 kbps interval (17.5 <= X < 22.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit INT25BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 25 kbps interval (22.5 <= X < 27.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit INT30BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 30 kbps interval (27.5 <= X < 32.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit 216/1553-HSC 103 12/16 Uen E | 2010-11-10 129 User Description, Radio Network Statistics INT35BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 35 kbps interval (32.5 <= X < 37.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit INT40BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 40 kbps interval (37.5 <= X < 42.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit INT45BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 45 kbps interval (42.5 <= X < 47.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit INT50BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 50 kbps interval (47.5 <= X < 52.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit INT55BREGPRSTBF Volume of RLC data successfully received by the MS in TBFs with a radio link bit rate in the 55 kbps interval (X => 52.5) for EGPRS, RLC acknowledged mode TBFs. Unit: kbit 6.9.3 Description The purpose of the radio link bitrate counters is to reflect the perceived radio link quality, which impact the throughput for the end-user. This sections details how the counters are stepped. If not otherwise stated the xSCHED/xACK counters in object types CELLGPRS and CELLGPRS0 and the INTx counters object type RLINKBITR are stepped according to the same logic. RLC Payload 130 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring RLC data blocks are used for the data transfer. These blocks contain either user data or GMM/SM signaling. Actual RLC payload data is defined as total RLC/MAC data volume excluding RLC control blocks and keep alive blocks. Only RLC payload data that has been successfully received, in the PCU for the uplink and in the MSs for the downlink, contributes to the total RLC payload data. The total amount of RLC payload data transferred is not exactly the same as the total amount of LLC data transferred. Each RLC data block contains LLC data plus one or more additional octets of spare bits. Also, if the final LLC PDU in the TBF does not completely fill the last RLC data block, filler octets are used to fill the remainder of the RLC data block. For example, if an EGPRS TBF consisted of one LLC PDU with size 70 octets, the RLC protocol might send one MCS-5 block (56 octets) and one MCS-1 block (22 octets). The total RLC payload data sent would be 78 octets, while the total LLC data sent would be 70 octets. RLC Acknowledged data The radio link bitrate counters only consider RLC acknowledged data, where retransmissions may occur. The volume of RLC unacknowledged data can be monitored on BSC level using counters in Object Type BSCQOS. RLC Data Blocks Used for Keep Alive Mechanisms RLC data blocks created by the RLC layer containing dummy LLC data, sent with the purpose to keep a downlink TBF alive, are excluded from the radio link bitrate counters. Packet Uplink Dummy Control Blocks received from a mobile during temporary inactive periods are also excluded from the radio link bitrate counters. This applies to data blocks sent on the uplink for TBFs in “Extended Uplink” mode and to data blocks sent on the downlink for TBFs in “Early Setup of Downlink TBF” mode or “Delayed Release of Downlink TBF” mode. Retransmissions Retransmissions are needed in case transmitted RLC data blocks are not successfully received. These retransmitted blocks are counted as scheduled, but the acknowledged data will only be counted once in the ACK counters. This means that the number of transmitted RLC data blocks exceeds the number of original RLC data blocks needed, which in turn will decrease the bitrate. Impact from coding schemes used A lower coding scheme is normally used at the beginning of a data transfer, independent of the radio quality. It will not be possible to switch to higher coding schemes until the PCU begins to receive measurement reports. For a downlink EGPRS transfer a number of radio block periods (up to 30) will elapse before the PCU can receive the first measurement report. Not using the highest possible coding scheme from the beginning of a transfer will have an effect on the radio link bitrate for small transfers. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 131 User Description, Radio Network Statistics At the end of a data transfer the coding scheme might change as well. The coding scheme chosen for the last RLC data block in a transfer is not really dependant on the radio link quality, but rather on the number of octets that need to be transferred. Also, a lower coding scheme at the end will increase the possibility of a successful transfer and minimize the risk of retransmissions. This will only have a minor effect on the measured radio link bitrate. To eliminate the effect of low radio link bitrate due to nonoptimal coding schemes, there are counters (please see Section 6.9.4 Radio Link Bitrate at optimum coding scheme according to LQC on page 136) that exclude the data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a data transfer. This way it will be possible to find out if a low radio link bitrate depends on a bad radio environment or if it is an effect of coding scheme ramp-up in combination with small transfers. Abnormally released TBFs Abnormally released TBFs occur when the contact with the MS is lost. For a downlink TBF the PCU will keep on scheduling radio blocks, ask for acknowledgements and retransmit data. After ten consecutive unanswered acknowledgement requests the TBF will be released and the data transmission will stop. For an uplink TBF the PCU will wait up to ten seconds since the last contact with the mobile before the TBF is released. In these cases, scheduled blocks up until the last successfully sent or received block contribute to the counters. This is because when the MS has lost contact with the BSS, the MS is no longer able to send any more data and counting these scheduled blocks would have a negative impact on the radio link bitrate measurements and does not have any relevance for the radio quality either. This also means that for TBFs where the MS never turns up, after the assignment has been sent, no scheduled blocks are counted. Scheduled Blocks and Measured RLC Payload on the Uplink The total number of times the PCU assigned a USF for the transmission of an uplink radio block is not the same as the number of times the MS actually scheduled a transmission of a new RLC data block. Occasionally the MS responds to a USF scheduling with a control block. These should not step the xSCHED counters. However, if the MS does not respond to a USF scheduling, the PCU interprets this as a lost data block and the xSCHED counter is stepped. The result could be that the xSCHED counters show slightly higher values than used for data transfer. Even if RLC control blocks are omitted, all scheduled USFs are not used by the MS to send new or to retransmit RLC data blocks that were not successfully received. As the uplink TBFs are normally very small (only a few radio blocks), this can potentially have a large impact on the measured radio link bitrate. To still obtain a radio link bitrate that is a good measure of the radio quality, the following special cases have been considered: • 132 Mobiles often do not react to the first 20 ms scheduling period. Therefore no scheduled blocks are counted on the uplink until an RLC data block has been correctly received. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring • At the end of a transfer there are a number of extra scheduling periods where the MS repeats the last sent blocks. This is due to the fact that it takes the radio block about 50 ms to travel between the MS and the PCU. When the uplink radio block is received in the PCU and the scheduling can be stopped, there are already a number of schedulings on their way. During this time the MS will keep on repeating the last RLC data block even though no retransmission has been ordered by the system. In these cases the RLC payload and the number of scheduled blocks are counted for the repeated uplink RLC blocks up until all previous blocks, including the CV=0 block, have been successfully received in the PCU. Then the counting stops. The repeated blocks are counted in these cases as the PCU cannot distinguish if an erroneous block was a repeated block or a new block. The counting starts again when a new RLC data block has been correctly received. • If the MS reaches the end of its send window it will resend previously non-acknowledged blocks. Again, for these repeated blocks the RLC payload and the number of scheduled blocks are counted by the system, as the PCU cannot distinguish a repeated erroneous block from a new erroneous block. Total RLC Payload Data Uplink per Cell As the repeated blocks on the uplink to a certain extent are included in the xACK counters (see above), it is not possible to use these counters to calculate the actual RLC payload data in the cell. Please use the counters ULINTBGVOL and ULGMMVOL in Object Type CELLGPRS3 instead. MCS-7 to MCS-9 For the higher modulation coding schemes, MCS-7, MCS-8 and MCS-9, two radio blocks are sent in one 20 ms channel time period. In these cases it is the number of 20 ms channel time periods that is counted and not the number of radio blocks. Summary The following table summarizes what is included in the different counters. Table 12 Summary of the Radio Link Bitrate Counters xSCHED/xACK counters in CELLGPRS, CELLGPRS2 and CELLGPRSO Retransmissions 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Included (xSCHED) / Excluded (xACK) INTx counters in RLINKBITR Included (channel time considered, but no RLC payload volume) 133 User Description, Radio Network Statistics xSCHED/xACK counters in CELLGPRS, CELLGPRS2 and CELLGPRSO INTx counters in RLINKBITR Included both in xSCHED and xACK counters up until all blocks including CV=0 have been correctly received Not applicable as the INTx counters only concerns the downlink RLC Acknowledged mode Included Included RLC Unacknowledged mode Excluded Excluded Abnormally released TBFs Included up until last correctly received radio block Included up until last radio block acknowledged by the MS Keep alive scheduling Excluded Excluded Included from first correctly received block Included from first radio block acknowledged by the MS DTM Included Included EIT Excluded Excluded Repeated block on the UL (not ordered by the system) Start of TBF 6.9.3.1 Radio Link Bit Rate Distributions for the Whole Cell (underlaid + overlaid Subcells) Counters are provided for CS-1/2/3/4 and EGPRS transfers on the downlink that allow a distribution of the radio link bit rates to be plotted. The formula used for CS–1/2/3/4 is : RLC_bitrate_GPRS(kbps) =((nr_of_first_sent_block_CS1 * 20*8) + (nr_of_first_sent_block_CS2 * 30*8) + (nr_of_first_sent_block_CS3 * 36*8) + (nr_of_first_sent_block_CS4 * 50*8)) / (total_nr_of_blocks * 20ms) The formula used for EGPRS is :RLC_bitrate_EGPRS(kbps) = ((nr_of_first_sent_block_MCS1 * 22*8) + (nr_of_first_sent_block_MCS2 * 28*8) + (nr_of_first_sent_block_MCS3 * 37*8) + (nr_of_first_sent_block_MCS4 * 44*8) + (nr_of_first_sent_block_MCS5 * 56*8) + (nr_of_first_sent_block_MCS6 * 74*8) + (nr_of_first_sent_block_MCS7 * 2*56*8) + (nr_of_first_sent_block_MCS8 * 2*68*8) + (nr_of_first_sent_block_MCS9 * 2*74*8)) / (total_nr_of_blocks * 20ms) A comment on the denominators in these formulas. Each RLC data block occupies 20 ms of air interface or channel time. The total amount of time 134 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring taken to send the information is defined as the total number RLC data blocks (transmissions and retransmissions) multiplied by 20 ms. Depending on the number of PDCH reserved for the users and how many users are sharing these PDCHs the MAC protocol may be able to schedule RLC data blocks often or only occasionally. However, this is of no relevance for these measures. All we are concerned with is the total number of RLC data blocks sent during the lifetime of the TBF. The STS counters for CS—1/2/3/4 are labelled [8 10 12 14 16 18]. Each of these counters represents a bit rate interval. At the end of every DL, RLC acknowledged, CS-1/2/3/4 mode TBF one of these counters is incremented by the volume of RLC payload data successfully sent in the TBF. Therefore the STS counters give the amount of RLC payload data that was successfully transferred within one of the specified bit rate intervals. The STS counters for EGPRS are labelled [10 15 20 25 30 35 40 45 50 55]. Each of these counters represents a bit rate interval. At the end of every DL, RLC acknowledged, TBF that used EGPRS one of these counters is incremented by the volume of RLC payload data successfully sent in the TBF. Therefore the STS counters give the amount of RLC payload data that was successfully received by the MS within one of the specified bit rate intervals. As an example say that in one CS–1/2/3/4 mode TBF eight RLC data blocks are coded using CS-2 and transmitted for the first time. The radio link quality then improves and in the same TBF seven RLC data blocks are coded using CS-3 and transmitted for the first time. However, twenty-one RLC data blocks actually needed to be sent before the information contained in the original fifteen blocks was successfully received by the mobile and the TBF ended (it does not matter what coding scheme was used for the retransmitted blocks only that an additional 6*20 ms were required for the information to be successfully received). Within the BSC the radio link bit rate for the TBF is calculated as (8*240 info. bits)+(7*293 info. bits)/(21*20ms)= 9.45 kbps. As a result the counter INT10BRGPRSTBF is incremented by 3.971 kbit. 6.9.3.2 Radio Link Bit Rate Averages for the Whole Cell (underlaid + overlaid Subcells) For all uplink and downlink transfer modes counters are provided which allow the average radio link bit rate over all TBFs to be calculated. 6.9.3.3 Radio Link Bit Rate Averages for the overlaid Subcell Only Counters are provided which allow the radio link quality for the overlaid subcell to be analyzed separately. It is also interesting to see the volume of RLC payload data that was transferred in the overlaid subcell as a percentage of the whole cell. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 135 User Description, Radio Network Statistics 6.9.4 Radio Link Bitrate at optimum coding scheme according to LQC When using the radio link bitrate counters described in previous sections and observing a low radio link bitrate, it may be difficult to determine if the low radio link bit rate is due to bad radio environment quality or due to large numbers of small transfers. This is because the above radio link bit rate counters include values taken during Coding Scheme ramp-up and ramp-down, respectively. (For small transfers the optimum coding scheme according to the LQC may never be reached). In order to simplify interpretations of a low observed radio link bitrate, a supplementary set of radio link bitrate counters is provided only operating at the optimum coding scheme according to the LQC algorithm, i.e. these counters exclude data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a data transfer. Hence, these counters reflect the radio link bitrate achieved when the coding scheme is controlled by radio quality only. These counters are found in object types CELLGPRS, CELLGPRS2 and CELLGPRSO, respectively, and are listed below. Note: Except for that these counters exclude data during coding ramp-up and ramp-down, they work in a similar fashion to the above discussed radio link bitrate counters in order to make counters comparable. CS14QDLSCHED Number of RLC data blocks scheduled for CS-1 to CS-4 and RLC acknowledged mode, downlink. Data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a transfer, are excluded. CS14QDLSCHEDSUB is the counter for transfers in the overlaid subcell. Units: Integer (number of blocks) CS14QDLACK Total amount of RLC data volume successfully acknowledged by MSs with a GPRS mode TBF (CS-1 to CS-4) in RLC acknowledged mode, downlink. Data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a transfer, are excluded. Units: bits CS14QDLACKSUB Total amount of RLC data volume successfully acknowledged by MSs in the overlaid subcell only, for CS-1 to CS-4 and RLC acknowledged mode, downlink. Data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a transfer, are excluded. Units: bits 136 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring MC19QDLSCHED Total number of 20 ms channel time periods (one or two EGPRS RLC data blocks) scheduled for MCS-1 to MCS-9 and RLC acknowledged mode, downlink. Data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a transfer, are excluded. MC19QDLSCHEDSUB is the counter for transfers in the overlaid subcell. Units: Integer (number of blocks) MC19QDLACK Total amount of RLC data volume successfully acknowledged by MSs with a EGPRS mode TBF (MCS-1 to MCS-9) in RLC acknowledged mode, downlink. Data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a transfer, are excluded. Units: bits MC19QDLACKSUB Total amount of RLC data volume successfully acknowledged by the MSs in the overlaid subcell only, for MCS-1 to MCS-9 and RLC acknowledged mode, downlink. Data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a transfer, are excluded. Units: bits MC19QULSCHED Total number of 20 ms channel time periods (one or two EGPRS RLC data blocks) scheduled for MCS-1 to MCS-9 and RLC acknowledged mode, uplink. Data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a transfer, are excluded. MC19QULSCHEDSUB is the counter for transfers in the overlaid subcell. Units: Integer (number of blocks) MC19QULACK Total amount of RLC data volume successfully acknowledged in the PCU for MCS-1 to MCS-9, RLC acknowledged mode uplink. Data blocks during coding scheme ramp-up at the beginning and ramp-down at the end of a transfer, are excluded. MC19QULACKSUB is the counter for transfers in the overlaid subcell. Units: bits 6.9.5 Suggested Formulae The table below gives a summary of the formulas that should be used for the calculation of the radio link bit rates. Since the units for the counters that 216/1553-HSC 103 12/16 Uen E | 2010-11-10 137 User Description, Radio Network Statistics accumulate the total amount of RLC payload data (i.e. CS12DLACK) is bits then dividing by the (number of RLC data blocks * 20ms) gives the average radio link bit rate in kbps. The units for the radio link bit rate interval counters (i.e. INT10BREGPRSTBF) are kbps. It is of course also important to assess the impact of the radio link quality by looking at the volume of RLC payload data for which a certain radio link bit rate was achieved. Downlink OL subcell Whole cell CS-1/2 CS-1/2/3/4 EGPRS Figure 7 CS12DLACK CS12DLSCHED*20ms CS12DLACKSUB CS12DLSCHEDSUB*20ms Distribution using INTXXGPRSTBF CS14DLACKSUB counters * CS14DLSCHEDSUB*20ms or average CS14DLACK/ CS14DLSCHED*20ms Distribution using MC19DLACKSUB INTXXEGPRSTBF count..** MC19DLSCHEDSUB*20ms or average MC19DLACK/ MC19DLSCHED*20ms Uplink Whole cell CS12ULACK CS12ULSCHED*20ms N/A (CS-1/2 only allowed on UL) MC19ULACK MC19ULSCHED*20ms OL subcell CS12ULACKSUB CS12ULSCHEDSUB*20ms N/A (CS-1/2 only allowed on UL) MC19ULACKSUB MC19ULSCHEDSUB*20ms Formulas for Calculation of the Radio Link Bit Rates Note: * Average is also possible to evaluate with (Sum INTXXBRGPRSTBF) / (CS14DLSCHED * 0.02s). ** Average is also possible to evaluate with (Sum INTXXBREGPRSTBF) / (MC19DLSCHED * 0.02s). The radio link bitrate is slightly underestimated due to abnormally released TBFs are not included in the INTX counters but in the XSCHED counters. 6.10 Level Two - GPRS Traffic Load 6.10.1 Introduction The GPRS traffic load counters primarily measure the number of TBFs that are sharing (or are “stacked up” on) the used PDCHs. This can have a large impact on the IP throughput that can be provided to each user and so is a very important level two performance measure. 138 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring The following is measured (please note that Dual Carrier DL is possible to measure separately using counters in Object Type TRAFEEVO): • Average number of simultaneous TBFs (or active users) in the cell • Average number of used PDCHs in the cell. • Average number of active PDCHs in the cell. • Average number of simultaneous TBFs per used PDCH in the cell. • Average number of simultaneous active TBFs per active PDCH in the cell. • Average QoS weight per used PDCH in the cell • Average number of effective streaming PDCHs in the cell A used PDCH is defined as a PDCH that carried at least one TBF (even if the TBF is in “Delayed release of DL TBF”, “Extended UL TBF”, or “Early Setup of DL TBF”). An active PDCH is defined as a PDCH that carried at least one TBF that is not in “Delayed release of DL TBF”, “Extended UL TBF”, or “Early Setup of DL TBF”. An active TBF is defined as a TBF sending payload data or having data in the downlink buffer, i.e. that is not artificially kept alive by “Delayed release of DL TBF”, “Extended UL TBF”, or “Early Setup of DL TBF”. If the average number of active TBFs per active PDCH = 2 then the available resources, the “pipes” that deliver the IP throughput, must be shared between 2 users (in a way determined by the QoS scheduling algorithms). The QoS weight per used PDCH shows the relative importance of the TBFs that are stacked up on the PDCHs. A high QoS weight per used PDCH means tougher competition for resources. These counters are implemented as scanning counters. A sample or scan of all TBFs in the cell is done every 10 seconds. The traffic situation in a cell can be very dynamic but the roughly 360 scans, taken in a 1 hour measurement period, give an accurate enough picture. The counters are implemented separately for B-PDCH, G-PDCH and E-PDCH so that the traffic load on these separate resource types can be monitored separately. Another aspect of the GPRS traffic load is to look at the total number of available RLC blocks and occupied RLC blocks. There are counters in the object type CELLGPRS3 for total number of available RLC blocks on all allocated PDCHs (will be the same for the uplink and downlink) and number of occupied RLC blocks, separate for the uplink and downlink. Also PDCHs in the packet idle list are considered as allocated. The number of occupied radio blocks considers all scheduled blocks regardless of usage and includes 216/1553-HSC 103 12/16 Uen E | 2010-11-10 139 User Description, Radio Network Statistics data blocks, control blocks, retransmissions, repetitions, dummy blocks and all scheduled blocks for abnormally released TBFs. Counters for GPRS utilization on EGPRS PDCH Counter: The 'EGPRS prioritized over GPRS' feature is used to increase the PS bandwidth by prioritize EGPRS over GPRS on EGPRS capable PDCHs. In order to monitor the feature 'EGPRS prioritized over GPRS' there are three counters included in object type TRAFDLGPRS: EPDCHGE, GETBFONPDCH and GNOETBFONPDCH, respectively. The values are scanned and accumulated to these counters every 10 seconds. The counter TRAFFDLGPRSSCAN is used as scanning counter and contains the number of samples. Please note that Dual Carrier DL is possible to measure separately using counters in Object Type TRAFEEVO. The following conditions are valid for the counters for GPRS utilization on EGPRS PDCHs: • 6.10.2 traffic classes Background, Interactive and Streaming (normal and EIT) are included • GMM/SM signaling is excluded • the downlink send buffer must not be empty • the MS must not be in DTM. Object Types and Counters Object type: TRAFDLGPRS. Title: GPRS/EGPRS Traffic Load counters for the downlink per cell. TRAFFDLGPRSSCAN Total number of scans (accumulations). 140 TBFDLGPRS Accumulated number of Basic and GPRS mode DL TBFs (active users), for all types of traffic, including effective streaming PDCH and PDCH used for EIT, in the cell. TBFDLEGPRS Accumulated number of EGPRS mode DL TBFs (active users), for all types of traffic, including effective streaming PDCH and PDCH used for EIT, in the cell. DLBPDCH Accumulated number of B-PDCH that carried one or more DL TBFs of any mode in the cell (a B-PDCH used on the DL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring DLGPDCH Accumulated number of G-PDCH that carried one or more DL TBFs of any mode in the cell (a G-PDCH used on the DL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. DLEPDCH Accumulated number of E-PDCH that carried one or more DL TBFs of any mode in the cell (an E-PDCH used on the DL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. DLTBFPBPDCH Accumulated number of simultaneous DL TBFs of any mode per used B-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. DLTBFPGPDCH Accumulated number of simultaneous DL TBFs of any mode per used G-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. DLTBFPEPDCH Accumulated number of simultaneous DL TBFs of any mode per used E-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. With Flexible Abis the counter values will be slightly higher. DLACTBPDCH Accumulated number of B-PDCH that carried one or more DL active TBFs of any mode in the cell (an active B-PDCH on the DL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. DLACTGPDCH Accumulated number of G-PDCH that carried one or more active DL TBFs of any mode in the cell (an active G-PDCH on the DL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. DLACTEPDCH Accumulated number of E-PDCH that carried one or more active DL TBFs of any mode in the cell (an active E-PDCH on the DL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. DLACTTBFPBPDCH Accumulated number of simultaneous active DL TBFs that are not in “Delayed release of DL TBF” or “Early Setup of DL TBF” of any mode per active B-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 141 User Description, Radio Network Statistics DLACTTBFPGPDCH Accumulated number of simultaneous active DL TBFs that are not in “Delayed release of DL TBF” or “Early Setup of DL TBF” of any mode per active G-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. DLACTTBFPEPDCH Accumulated number of simultaneous active DL TBFs that are not in “Delayed release of DL TBF” or “Early Setup of DL TBF” of any mode per active E-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. 142 STRBPDCH Accumulated number of effective streaming B-PDCH, excluding PDCH used for EIT. STRGPDCH Accumulated number of effective streaming G-PDCH, excluding PDCH used for EIT. STREPDCH Accumulated number of effective streaming E-PDCH, excluding PDCH used for EIT. QOSWDLBASIC Accumulated QoS weights on each used B-PDCH in the cell, for all types of traffic, excluding effective streaming PDCH, but including PDCH used for EIT. EIT TBFs on these PDCH are counted with a QoS weight of zero. QOSWDLGPRS Accumulated QoS weights on each used G-PDCH in the cell, for all types of traffic, excluding effective streaming PDCH, but including PDCH used for EIT. EIT TBFs on these PDCH are counted with a QoS weight of zero. QOSWDLEGPRS Accumulated QoS weights on each used E-PDCH in the cell, for all types of traffic, excluding effective streaming PDCH, but including PDCH used for EIT. EIT TBFs on these PDCH are counted with a QoS weight of zero. EPDCHGE The counter EPDCHGE counts the accumulated number of EGPRS PDCHs that are simultaneously reserved by at least one downlink EGPRS mode TBF and at least one downlink Basic mode or GPRS mode TBF. The counter is per cell. GETBFONPDCH The counter GETBFONPDCH contains the accumulated number of downlink Basic mode and downlink GPRS mode TBFs on each EGPRS PDCH reserved by at least one downlink EGPRS mode TBF. The counter is per cell. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring GNOETBFONPDCH The counter GNOETBFONPDCH contains the accumulated number of downlink Basic mode and downlink GPRS mode TBFs on each EGPRS PDCH not reserved by any downlink EGPRS mode TBF. The counter is per cell. Object type: TRAFULGPRS. Title: GPRS/EGPRS Traffic Load counters for the uplink per cell. TRAFFULGPRSSCAN Total number of scans (accumulations). TBFULGPRS Accumulated number of Basic and GPRS mode UL TBFs (active users), for all types of traffic, including effective streaming PDCH and PDCH used for EIT, in the cell. TBFULEGPRS Accumulated number of EGPRS mode UL TBFs (active users), for all types of traffic, including effective streaming PDCH and PDCH used for EIT, in the cell. ULBPDCH Accumulated number of B-PDCH that carried one or more UL TBFs of any mode in the cell (a B-PDCH used on the UL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULGPDCH Accumulated number of G-PDCH that carried one or more UL TBFs of any mode in the cell (a G-PDCH used on the UL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULEPDCH Accumulated number of E-PDCH that carried one or more UL TBFs of any mode in the cell (an E-PDCH used on the UL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULTBFPBPDCH Accumulated number of simultaneous UL TBFs of any mode per used B-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULTBFPGPDCH Accumulated number of simultaneous UL TBFs of any mode per used G-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULTBFPEPDCH Accumulated number of simultaneous UL TBFs of any mode per used E-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH 216/1553-HSC 103 12/16 Uen E | 2010-11-10 143 User Description, Radio Network Statistics used for EIT. With Flexible Abis the counter values will be slightly higher. ULACTBPDCH Accumulated number of B-PDCH that carried one or more active UL TBF of any mode in the cell (an active B-PDCH on the DL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULACTGPDCH Accumulated number of G-PDCH that carried one or more active UL TBF of any mode in the cell (an active G-PDCH on the DL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULACTEPDCH Accumulated number of E-PDCH that carried one or more active UL TBF of any mode in the cell (an active E-PDCH on the UL). Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULACTTBFPBPDCH Accumulated number of simultaneous active UL TBFs that are not in “Extended UL TBF” of any mode per active B-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULACTTBFPGPDCH Accumulated number of simultaneous active UL TBFs that are not in “Extended UL TBF” of any mode per active G-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. ULACTTBFPEPDCH Accumulated number of simultaneous active UL TBFs that are not in “Extended UL TBF” of any mode per active E-PDCH in the cell. Valid for all types of traffic, including effective streaming PDCH and PDCH used for EIT. 144 QOSWULBASIC Accumulated QoS weights on each used B-PDCH in the cell, for all types of traffic, excluding effective streaming PDCH, but including PDCH used for EIT. EIT TBFs on these PDCH are counted with a QoS weight of zero. QOSWULGPRS Accumulated QoS weights on each used G-PDCH in the cell, for all types of traffic, excluding effective streaming PDCH, but including PDCH used for EIT. EIT TBFs on these PDCH are counted with a QoS weight of zero. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring QOSWULEGPRS Accumulated QoS weights on each used E-PDCH in the cell, for all types of traffic, excluding effective streaming PDCH, but including PDCH used for EIT. EIT TBFs on these PDCH are counted with a QoS weight of zero. Object type: TRAFEEVO. Cell level Traffic Load Counters for EDGE Evolution. This object type gives the operator the possibility to obtain statistics about the usage of dual carriers. Note that all counters, except TSDCDL, in object type TRAFEEVO step only for TBFs with traffic class Background or Interactive. TBFs are only counted if there is enough data (> 500 B) in the send buffer (downlink). TBFDCDLCAP Number of downlink TBFs where the MS is capable of using dual carriers. TRAFDCDLTBF Number of downlink TBFs, in EGPRS mode, reserved on dual carriers. MAXDCTSDL Maximum possible number of time slots reservable for MSs on downlink TBFs in EGPRS mode, reserved on dual carriers. MUTILDCDL Sum of percentage shares of reserved time slots for all EGPRS mode downlink TBFs reserved on dual carriers related to the maximum possible reservable time slots. TRAFEEVOSCAN Number of scans for the counters in this object type. This counter is only valid for counters in object type TRAFEEVO. TSDCDL Number of time slots with one or more uplink or downlink TBFs currently reserved on dual carriers. Object type: CELLGPRS3. Title: Counters for number of available and used RLC blocks. AVAILRBLKS Total number of available 20 ms RLC blocks on all allocated PDCHs. The counters shows the number of available RLC blocks in one direction and will be the same for the uplink and the downlink. Also PDCHs in the packet idle list are considered. USEDDLRBLKS Total number of occupied (schedlued) 20 ms RLC blocks on the downlink. All types of RLC blocks counted including data blocks, control blocks, retransmissions, dummy blocks and all blocks for abnormally released TBFs 216/1553-HSC 103 12/16 Uen E | 2010-11-10 145 User Description, Radio Network Statistics USEDULRBLKS 6.10.3 Total number of occupied (scheduled) 20 ms RLC blocks on the uplink. All types of RLC blocks counted including data blocks, control blocks, retransmissions, repetitions, dummy blocks and blocks for abnormally released TBFs Description Every 10 seconds one scan of the cell is performed and a number of values recorded. E-TBF B-TBF B-TBF B B UL E-TBF B E E B-TBF E-TBF DL B-TBF Figure 8 Example Showing a 1 TRX Cell with 3 B-PDCH and 2 E-PDCH If the situation shown in the figure above existed in the cell when one scan was taken then the counters would be incremented by the following amounts. For the uplink: TRAFFULGPRSSCAN = ++1; TBFULGPRS = ++2; TBFULEGPRS = ++2; ULBPDCH = ++3 ; ULEPDCH =++2; ULTBFPBPDCH = ++5 (2 + 2 + 1 for the TBFs on the 3 used UL B-PDCH); ULTBFPEPDCH = ++4 (2 + 2 for the TBFs on the 2 used UL E-PDCH). For the downlink: TRAFFDLGPRSSCAN = ++1; TBFDLGPRS = ++2; TBFDLEGPRS = ++1; DLBPDCH = ++2 ; DLEPDCH =++2; DLTBFPBPDCH = ++3 (1 + 2 for the TBFs on the 2 used DL B-PDCH); DLTBFPEPDCH = ++4 (3 + 1 for the TBFs on the 2 used DL E-PDCH). The QoS weights on each TBF are summed vertically for each used PDCH (in a similar manner as for the TBF per PDCH counters). Note that the QoS weight per PDCH is not calculated for those PDCH that were effective streaming PDCH since streaming has absolute priority on those timeslots. The total accumulation of all the counters over the measurement period is the output from STS. Note that there are separate counters for PDCHs and TBFs per PDCH that only consider TBFs that are not in “keep alive” mode. These counters will provide a better picture of how the air interface resources are shared in the cell. Note though that even a TBF in “keep alive” mode will also be scheduled to a certain extent with dummy data. 146 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6.10.4 Suggested Formulae It will normally only be the busy hour traffic levels that are of interest. Some examples of suggested formulae: T BF ULEGP RS T RAF F ULGP RSSCAN T GP egtbful = Equation 61 T GP btppul = Equation 62 Average Number of Simultaneous EGPRS Tbfs (Active Users) on the Uplink ULT BF P BP DCH ULBP DCH Average Number of Simultaneous Tbfs of Any Mode per B-PDCH on the Uplink T GP bactippul = Equation 63 ULT BF P BACT P DCH ULBACT P DCH Average Number of Simultaneous Active TBFs of Any Mode per Active B-PDCH on the Uplink. Note that idle PDCHs, which are not carrying a TBF, are not counted at all. Therefore the minimum number of simultaneous TBF per PDCH =1. Using these counters it is possible to see if changing parameters or adding new hardware to create more available PDCH (of a certain type) will improve the IP throughput for the users. T GP qoswdlb = Equation 64 QOSW DLBASIC (DLBP DCH + ST RBP DCH ) Average Qos Weight per B-PDCH on the Downlink The number of times a user with a certain QoS weight is scheduled by the system (and so the users IP throughput) is also dependant on the QoS weights for the other users that share the PDCHs. A high average QoS weight per PDCH compared to other cells in the network means that there is tougher competition to be scheduled on the PDCHs. The effective streaming PDCHs must be compensated for in the downlink (it is assumed that there will be no effective streaming PDCHs in the uplink). It should be noted that QoS weight is also calculated for PDCHs carrying EIT where EIT transfers do not contribute to QoS weight. Therefore compensation is done for the bandwidth allocated by EIT. Following formula gives the percentage of the bandwidth in the cell used by EIT DL: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 147 User Description, Radio Network Statistics + RLCEDLEITSCHED) 3 100 [%] EITbw = (RLCGDLEITSCHED EIT sched + GPRSsched + MC 19DLSCHED Where : EITsched = RLCGDLEITSCHED + RLCEDLEITSCHED GPRSsched = CS 14DLSCHED + CS 12DLSCHED Equation 65 Percentage of RLC Data Blocks in the Cell Used by EIT DL The percentage of used RLC blocks compared to the total number of available RLC blocks on all allocated PDCHs can be calculated as (a similar formula can be created for the uplink): USEDrblks = USEDDLRBLKS AV AILRBLKS 3 100 [%] Equation 66 Percentage Occupied RLC Blocks Downlink of All Available RLC Blocks on All Allocated PDCHs 6.11 Level Two – GPRS Traffic load over Gb interface 6.11.1 Introduction Counters are available to measure average traffic volume, peak valuesand time congestion over the Gb interface. 6.11.2 Object Types and Counters Object type: GPRSCAP Title: GPRS capacity locks counters in BSC. 148 GBTRAFVOL Accumulated GPRS downlink data volume (LLC data + layer 2 and layer 3 headers) over Gb (in kbit). Layer 1 (FR/IP) headers are excluded. GBTRAFPEAK GBTRAFPEAK provides the peak value of Gb traffic throughput downlink (i.e. the minute with highest data volume) during a STS measurement period up to 60 min. Note: For longer measurement periods the counter will give the peak value from the last measured hour. GBTIMECONG Accumulated time when the Gb capacity limit has been exceeded. Please note GPRS data rate is calculated as average values per minute. The counter is only valid for Gb over IP. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6.11.3 Description Average GPRS data rate over Gb is obtained by dividing the counter GBTRAFVOL with the period length of the STS measurement report period (unit: kbit/s). It is suggested to compare average GPRS throughput and peak values to available BSC capacity, i.e. AXE parameter GBCAPACITY (print command DBTSP). 6.12 Level Two - CS Traffic Load and PDCH Allocation 6.12.1 Introduction The circuit switched traffic load is an extremely important factor for the performance of the GPRS system. Depending on the relative priority set between CS and PS traffic it can completely define the number of PDCH that are available for GPRS. Therefore if the GPRS traffic load counters are showing higher than wanted values for the average number of TBF per PDCH then the level of CS traffic should be checked, to see the average number of channels that were available for GPRS, together with the number of PDCH that actually were used. The diagram below shows some possible scenarios for two different cells within the packet switched busy hour — with the traffic channels used for circuit switched calls and the allocated PDCH varying over, a few samples of 10 seconds each. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 149 User Description, Radio Network Statistics PS allocated TS Cell A 25 20 Idle TS 15 CS used TS 10 5 0 Cell B 25 PS allocated TS 20 15 Idle TS 10 5 CS used TS 0 Figure 9 CS and PS Traffic Variation Over Time for Two Cells Say that the average value for the number of TBF per PDCH is higher than wanted in both Cell A and Cell B. In Cell A there is tough competition for the Basic Physical Channels (timeslots). It is probable that the high level of CS traffic is limiting the number of PDCH that could be allocated. Actions to consider for reducing the average number of TBFs per used PDCH are: • Add a TRX • Improve the packet switched GOS at the expense of the circuit switched GOS (PDCHPREEMPT and/or FPDCH and SPDCH) • Move CS traffic to other cells In Cell B there are a large number of idle channels. Actions to consider for reducing the average number of TBFs per used PDCH are: 150 • Reduce the TBFULLIMIT and/or the TBFDLLIMIT • Check the GSL device utilization in the PCU • Define additional dedicated and/or semi-dedicated PDCH (FPDCH and SPDCH) 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring The counters listed in this section help to determine which of the above scenarios is relevant . More details regarding appropriate actions can be found in the sections on “Adjusting the PDCH utilization” in Section 10 on page 231. Note that there will always be some small number of idle Basic Physical Channels. This is due to the random nature of the traffic and the efficiency of the PDCH allocation and CS allocation algorithms 6.12.2 PDCH Preemption PDCH preemption can be initiated due to different reasons: due to lack of CS TCHs, due to Abis congestion and due to PCU load regulation. Some counters include impact due to all types of preemption and can be used to see the subscriber impact due to preemption: • PREEMPTTBF shows the number of downlink and uplink TBFs released due to preemption, see Section 6.17.2 on page 166. • PREEMPTULREL shows the number of uplink TBFs released due to preemption, see Section 6.6 on page 116 • LDISTFI includes downlink IP buffer discards due to preemption, see Section 6.5 on page 113. Additionally there are a number of counters showing preemptions of PDCHs that makes it possible to see the resons for preemptions: 6.12.3 • PREEMPTPDCH Total number of used PDCHs, either carrying packet traffic, being in delayed release mode, early setup of downlink TBF mode or being in extended uplink mode, that have been preempted by CS traffic, either due to CS channel congestion, due to Abis congestion (CS only) or due to VGCS, see Section 6.17.1 on page 165. • PMTCSABCONG and PMTPSABCONG shows the number preempted PDCHs due to Abis congestion, see Section 7.3 on page 196. Object Types and Counters Object type: CELLGPRS (subset of all counters in object type) and CELLGPRSO (subset of all counters in object type). ALLPDCHACC 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Number of allocated PDCHs accumulator. Every 10 seconds the number of allocated PDCH in the cell is recorded and added to an accumulator. Divide by ALLPDCHSCAN to get the average number of allocated PDCH during the measurement period. Number of allocated PDCHs on channel group zero are counted separately by ALLPDCHACC0see Section 5.7.17 on page 81.ALLPDCHACCSUB is the counter for the overlaid subcell. 151 User Description, Radio Network Statistics ALLPDCHACTACC Number of used PDCHs accumulator. Every 10 seconds the number of used PDCH (carrying an uplink and/or downlink TBF) in the cell is recorded and added to an accumulator. Divide by ALLPDCHSCAN to get the average number of used PDCH during the measurement period. ALLPDCHACTACCSUB is the counter for the overlaid subcell. With Flexible Abis the counter values will be slightly lower. ALLPDCHPEAK Maximum number of PDCHs used, either carrying packet traffic, being in delayed release mode or being in extended uplink mode, per cell during the last 60 minutes. With Flexible Abis the counter values will be slightly lower. ALLPDCHSCAN Number of accumulations. The same value for both the allocated and active accumulators.ALLPDCHSCANSU B is the counter for the overlaid subcell. The other counters referred to in this section (in object types CELTCHF, CELTCHH and CLTCH) are described in Section 5.3 on page 36. 6.12.4 Suggested Formulae Again, it will normally only be the busy hour traffic levels that are of interest. The formula below gives the average number of basic physical channels that are usable as traffic channels but are not used for CS calls (the result is “IdleTS” + “PS allocated TS” in the graphs above). These are, or could potentially be, allocated as PDCH. T F T RALACC T HT RALACC T AV AACC P SnonCST S = 0 + 2 3 T HNSCAN T AV ASCAN T F NSCAN Equation 67 Average Number of Available (Working) Traffic Channels that Are Not Used for CS Calls The average number of PDCH actually allocated in the cell is given by: NoOfPDCUalloc = Equation 68 152 ALLP DCHACC ALLP DCHSCAN Average Number of Allocated PDCHs 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring The utilization of the PDCH that are allocated in the cell (100*ALLPDCHAC TACC/ALLPDCHACC)) may also be monitored. Attempts can be made to improve the PDCH utilization (and so the GSL device utilization) by reducing the average number of PDCH allocated in the cell (through PILTIMER settings for example). But there may still be some impact on the overall IP throughput due to the time required to allocate additional on-demand PDCH. 6.13 Level Two - Multislot Utilisation (PDCH Reservation) 6.13.1 Introduction The number of timeslots that each MS manages to reserve compared to the maximum it was capable of is an important factor in determining the IP throughput achieved for a user. These counters are implemented as scanning counters. That is every 10 seconds all TBFs in the cell, that are engaged in the transfer of interactive or background data, are scanned to see how many timeslots are actually reserved out of the maximum number possible according to the multislot class. This allows statistics for the multislot utilization to be calculated and is much less complex than trying to keep track of the result of all reservations, upgrades and re-reservations in the cell. If the GPRS traffic load counters are thought of as showing how all the TBFs are stacked vertically on the allocated PDCH then the multislot utilization counters complete the overall picture by showing how all the TBFs have been reserved horizontally on the allocated PDCH. The multislot utilization is primarily dependant on the number of adjacent PDCH that can be allocated by the system. The counters are implemented separately for Basic, GPRS and EGPRS mode TBFs so that the reservations for these different TBF modes can be monitored separately. The counters can also be used to help: 6.13.2 • Estimate the maximum achievable IP throughput in the cell. This can be done using the counters which give the average “maximum number of reservable timeslots” separately for B-TBFs/G-TBFs and E-TBFs. The measured average IP throughput can then be compared with the estimated maximum achievable IP throughput. • Dimension the optimal number of E-PDCHs. This can be done by comparing the average number of simultaneous E-TBFs with the average number of simultaneous TBFs for EGPRS capable MSs. Object Types and Counters Object type: TRAFGPRS2 and TRAFEEVO. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 153 User Description, Radio Network Statistics Title: GPRS/EGPRS multislot utilization counters per cell downlink, 20 counters. All these counters exclude DTM transfers or attempted transfers. All the counters also exclude contribution from TBFs carrying EIT. MUTILBASIC Accumulation of the percentage of number of timeslots actually reserved versus maximum number of timeslots possible for the MS to reserve, calculated for every DL Basic mode TBFs scanned. One scan of all downlink TBFs in the cell carried out every 10 seconds. Counter for GPRS mode TBFs MUTILGPRS. Counter for EGPRS mode TBFs MUTILEGPRSWith Flexible Abis the counter value of MUTILEGPRS will be slightly lower. Units: Percent TRAFGPRS2SCAN Total number of scans of the cell carried out for the number of DL TBFs. This counter is only valid for counters in object type TRAFGPRS2. TRAFF2BTBFSCAN Total number DL TBFs scanned which were of mode Basic. Counter for GPRS mode TBFs TRAFF2GTBFSCAN. Counter for EGPRS mode TBFs TRAFF2ETBFSCAN. MAXGTSDL Accumulation of maximum possible number of timeslots reservable by the MS for all DL B-TBFs and G-TBFs scanned. MAXEGTSDL Accumulation of maximum possible number of timeslots reservable by the MS for all DL E-TBFs scanned. MUTIL15 Number of DL TBFs (of any mode) scanned where only 1 out of a possible 5 timeslots were reserved. Also MUTIL25, MUTIL35, MUTIL45, MUTIL55. With Flexible Abis the counter values will be affected. For MUTIL15, MUTIL25, MUTIL35 and MUTIL45 the values will be slightly higher and for MUTIL55 slightly lower. MUTIL14 Number of DL TBFs (of any mode) scanned where only 1 out of a possible 4 timeslots were reserved. Also MUTIL24, MUTIL34, MUTIL44. With Flexible Abis the counter values will be affected. For MUTIL14, MUTIL24 and MUTIL34 the values will be slightly higher and for MUTIL44 slightly lower. 154 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring MUTIL13 Number of DL TBFs (of any mode) scanned where only 1 out of a possible 3 timeslots were reserved. Also MUTIL23, MUTIL33. With Flexible Abis the counter values will be affected. For MUTIL13 and MUTIL23 the values will be slightly higher and for MUTIL33 slightly lower. MUTIL12 Number of DL TBFs (of any mode) scanned where only 1 out of a possible 2 timeslots were reserved. Also MUTIL22. With Flexible Abis the counter values will be affected. For MUTIL12 the values will be slightly higher and for MUTIL22 slightly lower. TBFDLGPRSCAP Number of simultaneous DL TBFs for GPRS only capable mobiles in a cell. TBFDLEGPRSCAP Number of simultaneous DL TBFs for EGPRS capable mobiles in a cell. TRAFDCDLTBF Number of downlink TBFs, in EGPRS mode, reserved on dual carriers. MAXDCTSDL Maximum possible number of time slots reservable for MSs on downlink TBFs in EGPRS mode, reserved on dual carriers. MUTILDCDL Sum of percentage shares of reserved time slots for all EGPRS mode downlink TBFs reserved on dual carriers related to the maximum possible reservable time slots. Object type: TRAFGPRS3. Title: GPRS/EGPRS multislot utilization counters per cell uplink, 20 counters. All these counters exclude DTM transfers or attempted transfers. All the counters also exclude contribution from TBFs carrying EIT. MUTILBASICUL Accumulation of the percentage of number of timeslots actually reserved versus. maximum number of timeslots possible for the MS to reserve, calculated for every UL Basic mode TBFs scanned. One scan of all uplink TBFs in the cell carried out every 10 seconds. Counter for GPRS mode TBFs MUTILGPRSUL. Counter for EGPRS mode TBFs MUTILEGPRSUL TRAFGPRS3SCAN Total number of scans of the cell carried out for the number of UL TBFs. This counter is only valid for counters in object type TRAFGPRS3. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 155 User Description, Radio Network Statistics BULTBFSCAN Total number UL TBFs scanned which were of mode Basic. Counter for GPRS mode TBFs GULTBFSCAN. Counter for EGPRS mode TBFs EULTBFSCAN. MAXGTSUL Accumulation of maximum possible number of timeslots reservable by the MS for all UL B-TBFs and G-TBFs scanned. MAXEGTSUL Accumulation of maximum possible number of timeslots reservable by the MS for all UL E-TBFs scanned. MUTIL14UL Number of UL TBFs scanned where 1 out of 4 maximum reservable timeslots were reserved. Also MUTIL24UL, MUTIL34UL, MUTIL44UL. MUTIL13UL Number of UL TBFs scanned where 1 out of 3 maximum reservable timeslots were reserved. Also MUTIL23UL, MUTIL33UL. MUTIL12UL Number of UL TBFs scanned where 1 out of 2 maximum reservable timeslots were reserved. Also MUTIL22UL. TBFULGPRSCAP Accumulation of number of simultaneous UL TBFs for GPRS only capable mobiles in a cell. TBFULEGPRSCAP Accumulation of number of simultaneous UL TBFs for EGPRS capable mobiles in a cell. 6.13.3 Description Every 10 seconds a scan is made of all the downlink TBFs in the cell. The following values are recorded for each downlink TBF: • The maximum number of timeslots possible for the MS to reserve • The percentage of number of timeslots actually reserved versus maximum number of timeslots reservable by the MS. • The TBF mode (Basic, GPRS, EGPRS) For most multislot classes the maximum number of timeslots reservable by the MS in the downlink and uplink is the same as the maximum number of timeslots allowed by the mulitslot class. However, for some multislot classes it could also be limited by reservations in the opposite direction. For example a class12 MS may have a maximum of 5 timeslots reserved at any one time — but this could be, for example, 2 TS reserved on the UL (then the maximum number of timeslots reservable by the MS on the DL = 3) or 3 TS reserved on the UL (then the maximum number of timeslots reservable by the MS on the DL = 2 and so on). 156 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring The accumulation of the maximum number of timeslots reservable by the MS for all DL TBFs scanned over the measurement period is given by MAXGTSDL and MAXEGTSDL. The sum of the precentages, number of timeslots actually reserved versus maximum number of timeslots reservable by the MS, for each DL Basic mode TBFs scanned = MUTILBASIC (and similar for MUTILGPRS and MUTILEGPRS). In addition there are a group of counters that increment depending on the value of the fraction calculated for each TBF. For example if the fraction (number of timeslots actually reserved/ max. number of timeslots possible for the MS to reserve) = 3/4 for one of the TBFs scanned then the counter MUTIL34 is incremented by 1. Note: 6.13.4 To allow better correlations with the throughput counters the counters only steps for TBFs that are actively engaged in the transfer of interactive or background user data and exclude small transfers with a buffer size less than 500 bytes (DL only). This means that the following TBFs are excluded: • TBFs in keep alive mode sending dummy data • TBFs used for the Streaming traffic class • TBFs used for GMM/SM signalling Suggested Formulae The average number of maximum possible timeslots that were reservable by mobiles on the downlink is given by: P Smax = MAXGT SDL + MAXEGT SDL T RAF F 2BT BF SCAN + T RAF F 2GT BF SCAN + T RAF F 2ET BF SCAN Equation 69 Average Maximum Number of TS Reservable by MSs for Downlink TBFs For calculating the average maximum number of TS reservable by MSs for Dual Carrier Downlink EGPRS TBFs the following formula applies: P SmutilDCDL = Equation 70 MAXDCT SDL T RAF EEV OSCAN Average Maximum Number of TS Reservable by MSs for Dual Carrier Downlink EGPRS TBFs The average utilisation of those timeslots is given by: P SmutilALL = Equation 71 MUT ILBASIC + MUT ILGP RS + MUT ILGP RS [%] T RAF F 2BT BF SCAN + T RAF F 2GT BF SCAN + T RAF F 2ET BF SCAN Average Multislot Utilization for All DL TBFs The multislot utilization for each TBF mode can also be calculated separately: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 157 User Description, Radio Network Statistics P SmutilBASIC = Equation 72 MUT ILBASIC [%] T RAF F 2BT BF SCAN Average Multislot Utilization for DL Basic Mode Tbfs For calculating multislot utilization for Dual Carrier the following formula applies: P SmutilDCDL = Equation 73 MUT ILDCDL [%] T RAF EEV OSCAN Average Multislot Utilization for Dual Carrier DL EGPRS TBFs The ratio of E-TBFs to TBFs for EGPRS capable mobiles is given by: P SmutilMScap = Equation 74 T BF DLEGP RSCAP 3 100 [%] T RAF F 2ET BF SCAN Ratio of E-Tbfs to Tbfs for EGPRS Capable Mobiles An example of a distribution that can be constructed from the MUTIL”X”4 counters: Multislot utilisation Maximum reservable TS =4 Percentage of scanned DL TBFs % 50 40 30 20 10 0 1/4 Figure 10 158 2/4 3/4 4/4 Multislot Utilization Distribution for Maximum Reservable TS = 4 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6.14 Level Two - Mobility 6.14.1 Introduction The mobility of the user will affect the IP throughput that a user receives. If they remain in one cell for the duration of the data session then there will be no impact. If they move rapidly between cells there will be a large impact. The counters described here enable cells in which users experience a relatively high number of cell reselections to be identified. A discard of the contents of a downlink buffer has a larger impact on the user compared to a move of the contents of the buffer. It is also worth stating again that how the user experiences an interruption due to cell reselection is very dependant on the type of application he/she is running. 6.14.2 Object Types and Counters Object type: CELLGPRS2. Title: Mobility, 2 counters (subset of all counters in object type). FLUDISC Number of times the entire contents of a downlink buffer in the PCU were discarded due to an inter RA cell reselection or inter PCU cell reselection (i.e. Flush message received in PCU that deleted the contents of a PCU buffer). Same counter as described in Section 6.5 on page 113. Units: integer FLUMOVE 6.14.3 Number of times the contents of a downlink buffer in the PCU were moved to another queue due to a flush message received in the PCU. Description Note that the counters are not stepped if the PCU buffer was empty when the decision was taken since there is no impact to the user in this case. A PCU buffer that contains only GMM/SM signalling LLC-PDUs is considered to be an empty buffer (since a discard will not have any affect on the TCP or UDP protocols). For DTM transfers the contents of the PCU buffer will already be discarded by the PCU before the FLUSH message is received from the SGSN. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 159 User Description, Radio Network Statistics 6.14.4 Suggested Formulae The absolute number of flush discards and flush moves are relevant performance indicators since this shows that the higher layer protocols for one users data transfer have been impacted. For a relative comparison of performance between different cells it is suggested to calculate the number of DL buffer discards or moves per data transfer session minutes (estimated with the number of downlink TBF minutes). P SfluCLM = Equation 75 (T BF DLGPRS + T BF DLEGP RS ) =6 [mins] F LUDISC + F LUMOV E Average Downlink Data Session Transfer Minutes per Flush Discard or Move 6.15 Level Two - GSL Device Utilisation 6.15.1 Introduction Counters are provided that allow the average GSL device utilization and a distribution of the GSL device utilization to be calculated. This is an extremely important measure to confirm that service quality provided to the GPRS users is not being limited by lack of GSL devices and for longer term dimensioning of the PCU. The impact of changing parameter settings on the GSL device utilization, such as the PILTIMER parameter and the number fixed PDCH per cell, can also be assessed. 6.15.2 Object Types and Counters Object type: BSCGPRS. Title: GSL device utilization counters, (subset of all counters in object type) GSLMAX 160 The counter GSLMAX is the maximum number of GSL Sub devices possible to use at each scan. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Note: GSLMAX may differ between each scan. It depends on the following factors: Seized GSL Capacity Remaining Processing Capacity in the physical link layer Remaining Idle GSL Sub Device Capacity First a calculation is performed to obtain the remaining Processing Capacity in the physical link layer. Then the remaining Idle GSL Sub Device Capacity is calculated. The smallest of these values is used as the figure for how sub many devices that could be used as GSL sub channels. The result is added to the current number or Seized GSL devices to obtain GSLMAX. GSLMAX can also be expressed with the following algorithm: GSLMAX = GSL Sub Dev Seized as B-PDCH + (GSL Dev Seized as Gor E-PDCH * 4) + min[GSL Sub Dev Available due to processing capacitylimits of the physical link layer, Number of Idle GSL Sub Devices]. GSLUTIL Accumulation of the percentages (GSL devices in use / maximum GSL devices possible to use) taken at each scan. Units: sum of percentages for each scan GSLSCAN Total number of scans of the PCU taken in relation to the GSL device utilization. GSL0040 Number scans where the fraction of (GSL devices in use / maximum GSL devices possible to use) is between 0% and 40%. GSL4160 Number scans where the fraction of (GSL devices in use / maximum GSL devices possible to use) is between 41% and 60%. GSL6180 Number scans where the fraction of (GSL devices in use / maximum GSL devices possible to use) is between 61% and 80%. GSL8190 Number scans where the fraction of (GSL devices in use / maximum GSL devices possible to use) is between 81% and 90%. GSL9100 Number scans where the fraction of (GSL devices in use / maximum GSL devices possible to use) is between 91% and 100%. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 161 User Description, Radio Network Statistics 6.15.3 Description Every 11 seconds a scan of the PCU is carried out the following values recorded: • The maximum number of 16 kbps GSL devices that were available for use. Two separate calculations are done for this part. The first calculates the maximum according to the remaining processing capacity in the physical link layer. The second calculates the maximum according to the physically available (deblocked) 16 kbps GSL devices. The smallest value is then taken as the number of GSL devices that were available for use. • The fraction of (used GSL 16 kbit / maximum GSL devices available for use). One 64 kbps GPRS signalling link is assumed to use 1.5 times the DSP capacity of one 16 kbps GPRS signalling link. One 64 kbps GPRS signalling link requires four physical 16 kbps GSL devices. Devices that are allocated to the Gb interface are not considered in either of these calculations. i.e. it is only GSL devices that are usable for the Abis interface that are considered. 6.15.4 Suggested Formulae P SgslutilMAX = Equation 76 GSLMAX GSLSCAN Average Number of Usable 16 kbps GSL Devices The average utilization of those timeslots is given by: P Sgslutil = Equation 77 GSLUT IL [%] GSLSCAN Average Utilization of the Usable 16 kbps GSL Devices. A graph of the GSL device utilization can also be plotted: 162 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Number of scans [%] 50 40 30 20 10 0 0-40 41-60 61-80 81-90 91-100 GSL device utilisation at scan [%] Figure 11 Graph of the 16 kbps GSL Device Utilization. The counter FAILMOVECELL described in Section 6.17.5 on page 171can also be useful in identifying lack of GSL devices in the PCU. 6.16 Level Two - GPH RP Load 6.16.1 Introduction Counters are available that allow a distribution of the CPU load on all GPH RPs to be presented as a distribution (per PCU). An additional counter per GPH RP is provided that can pinpoint high load on a specific GPH RP. Another way to verify that the PCU is properly dimensioned with respect to PCU load are the counters connected to PCU Load Control, see Section 6.17.12 on page 187. 6.16.2 Object Types and Counters Object type: BSCGPRS2. Title: RPP load per PCU. RPP0040 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Total number of scans where the RPP load was between 0% and 40% 163 User Description, Radio Network Statistics RPP4160 Total number of scans where the RPP load was between 41% and 60%. RPP6180 Total number of scans where the RPP load was between 61% and 80% RPP8190 Total number of scans where the RPP load was between 81% and 90% RPP9100 Total number of scans where the RPP load was between 91% and 100% Object type: BSCGPRS2. Title: GARP-2 load per PCU. G2GPH0040LOAD Total number of scans where the GARP-2 load was between 0% and 40%. G2GPH4160LOAD Total number of scans where the GARP-2 load was between 41% and 60%. G2GPH6180LOAD Total number of scans where the GARP-2 load was between 61% and 80%. G2GPH8190LOAD Total number of scans where the GARP-2 load was between 81% and 90%. G2GPH9100LOAD Total number of scans where the GARP-2 load was between 91% and 100%. Object type: EMGPRS. Title: Load per RP-. RPPLOAD 6.16.3 The counter value is incremented each time (scan) the RP processor load is greater than 80%. Note that the counter is used for all RP platforms in the PCU. Description Every 500 ms each working GPH RP in the PCU is scanned and the load for that RP recorded. Say there is a PCU with three RPPs. If the load on RPP1 = 45%, on RPP2 = 82% and on RPP3 = 75% at one scan then: 164 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring • RPP4160 is incremented by 1, RPP8190 is incremented by 1 and RPP6180 is incremented by 1. • RPPLOAD is incremented by 1 for the counter related to RPP2. The counters for GPH RP on GARP-2 works in the same way as described above, but for GARP-2 platform. 6.16.4 Suggested Formulae It is suggested to plot a distribution of the GPH RP load per PCU. 6.17 Additional Counters 6.17.1 PDCH Allocation and Preemption This section details the counters, in the object types CELLGPRS and CELLGPRS2, related to access attempts by the GPRS MS on specific channels, CS pages received in the PCU via the SGSN (Gs interface) and some additional counters for PDCH allocation and preemption. Object type: CELLGPRS Title: GPRS counters per cell. PCHALLATT Number of packet channel allocation attempts. The counter value is incremented at each request to allocate PDCHs in the cell. The counter value is incremented by one independently of the number of channels requested and the result of the request. Requests to allocate PDCHs occurs when the operator increases the number of dedicated PDCHs and when the packet data traffic demands on-demand PDCHs. No request to allocate PDCHs is done if there are no deblocked traffic channels in the cell. PCHALLFAIL Number of packet channel allocation failures. A failure is when zero PDCH could be allocated due to lack of basic physical channels over the air interface. Note that the failure relates to the inability of the system to allocate resources and, in most cases, not to any failure to reserve channels experienced by the user. “Failures” are normal, frequent, occurrences in a situation where PS traffic must compete with CS traffic for basic physical channels. PREEMPTPDCH Total number of used PDCHs preempted by CS traffic, per cell, either due to CS channel congestion, due to Abis congestion (CS only) or due to VGCS. The 216/1553-HSC 103 12/16 Uen E | 2010-11-10 165 User Description, Radio Network Statistics counter value is incremented in the RP of the PCU when the packet data traffic has been removed from the preempted PDCH. PREEMPTPDCHSUB in object type CELLGPRSO is the counter for the overlaid subcell. The level two counters for multislot utilization give a more comprehensive picture of channel reservations for the users. The packet channel allocation failure rate can be calculated as: P CHFAIL = P CHALLF AIL 3 100 [%] P CHALLAT T Equation 78 Packet Channel Allocation Failure Rate Note: Note that the failure relates to the inability of the system to allocate resources and, in most cases, not to any failure to reserve channels experienced by the user. “Failures” are normal, frequent, occurrences in a situation where PS traffic must compete with CS traffic for basic physical channels. Object type: CELLGPRS2 Title: GPRS counters per cell. PMTATT Total number of PDCH preemption attempts per cell. Preemption attempts are only counted if there is at least one PDCH possible to preempt, that is, the PDCH must be an on-demand PDCH and conditions for frequency band and sub cell must be fulfilled. Note: PMTREF Total number of attempts to preempt on-demand PDCH refused because of the PDCHPREEMPT parameter. The system will then attempt other types of preemption (i.e. HSCSD and priority preemptions with the feature eMLPP). If these preemptions also fail a blocked call in the cell will result. The call attempt may still succeed in another cell through the feature Assignment to Other Cell. Note: 6.17.2 Each CS call attempt can result in PDCH preemption attempts in several cells Each CS call attempt can result in PDCH preemption attempts in several cells TBF Establishment and Release This section details the counters related to TBF establishment and release on cell level in the object type CELLGPRS. Object type: CELLGPRS 166 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Title: GPRS counters per cell. DLTBFEST The total number of attempts to establish a downlink TBF. FAILDLTBFEST The total number of attempts to establish a downlink TBF that resulted in a failure due to lack of resources. Lack of resources could mean: no PDCH allocated on which the TBF could be reserved; no TFIs available (i.e. maximum allowed number of TBF reserved on all allocated PDCH); the PDCH was preempted before it could be reserved; some other channel fault that prevented the reservation; congestion in MAC (i.e. no frame number could be returned); congestion in the CP prevented the request being processed. PREEMPTTBF The counter PREEMPTTBF is incremented each time a downlink or uplink TBF is released due to PDCH preemption. Reasons for PDCH preemptions are CS channel congestion, Abis congestion (CS only) and VGCS. MOVECELLTBF Number of released TBFs due to move of cell from one GPH RP to another. This is may be due to high RPP GPH processor load or lack of GSL devices. All TBFs are taken down and GPRS support in the cell is removed while the BVC is reallocated. FAILDLANSW The counter FAILDLANSW counts the number of DL TBF establishment attempts that failed due to one of the following reasons: No answer from MS, Access Delay > max TA, Packet Control Ack syntax error. CELLMOVED Counts the number of times a cell has been successfully moved from one RPP to another. Move of cell can either be initiated due to lack of GSL devices or due to high GPH processor load. The number of cells moved due to high GPH processor load can be monitored on BSC level, see Section 6.17.12 on page 187. This counter should be summed over all cells in order to compare with the counter FAILMOVECELL on BSC level. TBFPREEMPEST Each time a TBF is released due to preemption a timer is started that counts the time until the next TBF was successfully established in the cell. TBFPREEMPEST is the sum of these times in milliseconds. Dividing by PREEMPTTBF gives the average time between a release due to preemption and the next successful TBF establishment in the cell. Under high GPRS traffic loads this indicates the average length of the interruption to the users service at BSS level for each preemption. If the time between the TBF release (due to PDCH 216/1553-HSC 103 12/16 Uen E | 2010-11-10 167 User Description, Radio Network Statistics preemption) and the next successful establishment exceeds 30 seconds, the counter will be incremented with 30000 ms. 6.17.3 Counters for CCCH Messages and CCCH Load 6.17.3.1 AGCH/PCH All Paging messages to be sent on the PCH and all Access Grant messages to be sent on the AGCH are queued in the BTS. The location area dimensioning guideline, see Reference [5], contains a full description of how to use the counters in object type CELLPAG to determine if there is a congestion problem on the PCH (from the ratio of pages discarded in the BTS to pages received in the BTS). One counter shows the number of messages for the AGCH that are discarded by the BTS, the messages are only discarded if the queue is full in the BTS. Note that Access Grant messages have priority over Paging messages There are additional counters for checking the number of messages for the AGCH sent from the BSC/PCU. There is also one counter for the number of CS pages that are to be sent on the PCH in one specific cell. These counters are listed below: Object type: CCCHLOAD Title: Counters for messages transmitted on the AGCH. 168 CSIMMASS Number of CS IMMEDIATE ASSIGNMENT messages sent on the CCCH. REJCSIMMASS Number of CS IMMEDIATE ASSIGNMENT REJECT messages sent on the CCCH. PSIMMASS Number of PS IMMEDIATE ASSIGNMENT messages sent on the CCCH. The counter is stepped twice for a segmented PS IMMEDIATE ASSIGNMENT message (i.e. two messages are actually sent over the CCCH when the original message has been segmented). REJPSIMMASS Number of PS IMMEDIATE ASSIGNMENT REJECT messages sent on the CCCH. Timer T3142 (as specified in the WAIT INDICATION information element) is started in the GPRS MS on receipt of this message. The MS is not allowed to attempt to access the system again, from the same cell, until this timer has expired. If the timer expires before a relevant IMMEDIATE ASSIGNMENT message is received then “TBF establishment failure” will be notified to the layers above RLC/MAC in the GPRS MS. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring DISCIMMASS Number of PS and CS IMMEDIATE ASSIGNMENT and IMMEDIATE ASSIGNMENT REJECT messages that are discarded in the BTS. The messages are only discarded due to full queue in the BTS. Object type: CELLGPRS Title: GPRS counters per cell (subset of all counters in the object type). Number of 48.018 PAGING CS messages to be sent on the PCH in the cell, sent from the SGSN on cell level only (i.e. sent only to this specific cell since the MS is still in Ready state in the cell). PAGCSBVCI The percentage discarded AGCH messages in a cell can be calculated as: IAdisc DISCIM M ASS = P SIM M ASS + CSIM M ASS + REJ P SIM ASS + REJ CSIM ASS 3 100 [%] Equation 79 6.17.3.2 Percentage Discarded AGCH Messages Due to Full Queue in the BTS RACH A large load on the RACH will create a large load on the AGCH, which will in turn steal resources from the PCH. Therefore, again, if the ratio of pages discarded in the BTS to pages received in the BTS is very small a congestion problem on the RACH is very unlikely. However there is one counter for the number of Channel Request messages for PS received in the PCU. Object type: CELLGPRS Title: GPRS counters per cell (subset of all counters in the object type). PDRAC Incremented once for each Channel Request message for PS, originating from a set of random access bursts on RACH, successfully received by the PCU from the BSC. 6.17.4 Counters for PCCCH Messages and PCCCH Load 6.17.4.1 PAGCH/PPCH All paging messages to be sent on the PPCH and all Access Grant messages to be sent on the PAGCH are queued in the PCU. The counters listed below can be used to measure the load on the PPCH from the ratio of discarded paging messages in the PCU. No counters are provided for the PAGCH since Access Grant messages have priority over Paging messages. Therefore it is very unlikely a congestion problem exists on the PAGCH if no congestion problem is measured on the PPCH. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 169 User Description, Radio Network Statistics Object type: CELLGPRS2. Title: GPRS counters per cell (subset of all counters in the object type). All these counters exclude DTM transfers or attempted transfers. PAGDISCPPCH Total number of 48.018 PAGING CS and 48.018 PAGING PS messages to be sent on PPCH in the cell and were discarded. PAGCSONPPCH Total number of 48.018 PAGING CS messages to be sent on PPCH in the cell, which were sent from the SGSN on cell level or RA level. PAGPSONPPCH Total number of 48.018 PAGING PS messages to be sent on PPCH in the cell, which were sent from the SGSN on cell level or RA level. Object type: CELLGPRS Title: GPRS counters per cell (subset of all counters in the object type). PPAGCSBVCI 6.17.4.2 Number of 48.018 PAGING CS messages to be sent on PPCH in the cell, sent from the SGSN on cell level only (i.e. sent only to specific cell since the MS is still in Ready state in the cell). PRACH The ratio of uplink blocks on the MPDCH used for traffic or reserved for the PRACH is set by parameter. Therefore it can be important to monitor the load on the PRACH. The following STS counters are available per cell: Object type: CELLGPRS2. Title: GPRS counters per cell (subset of all counters in the object type). All these counters exclude DTM transfers or attempted transfers. 170 PCHRREQ Number of Packet Channel Request and EGPRS Packet Channel Request messages received on the PRACH. PCHRZRETRY Number of uplink TBFs that were initiated by the MS with a Packet Channel Request or EGPRS Packet Channel Request message on the first try (retry bit in MAC header set to zero). PCHROPRETRY Peak value for the number of uplink TBFs that were initiated by the MS with a retransmitted Packet Channel 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Request or EGPRS Packet Channel Request message (the first request was lost, e.g. collision on the Um interface). The percentage of uplink TBFs that were initiated with a retransmitted request is calculated every five seconds. Every five minutes the status counter PCHROPRETRY is updated with the recorded peak percentage from the last 15 minute period. PCHRSCAN Scan counter for the PRACH statistics. Number of intervals for which the value described above has been calculated. Object type: CELLGPRS Title: GPRS counters per cell (subset of all counters in the object type). PDPRAC 6.17.5 Incremented once for each Packet Channel Request message, originating from a set of random access bursts on PRACH, successfully received by the PCU from the BTS. Additional BSC Counters for GPRS The object types BSCGPRS and BSCGPRS2 contains counters for GPRS/EGPRS on BSC level in addition to those provided in the quality of service counters. ALLPDCHPCUATT Total number of attempts to allocate GSL resources for a set of one or more PDCHs. Note: Please note that this counter are not recommendable to use for PS resource utilization as it is affected by code changes between projects. To determine PCU/GSL device allocation failure rate, please use the following counters/formula instead: 100*ALLPDCHPCUFAIL/ALLPDCHPCUATT [%] ALLPDCHPCUFAIL Number of failed PDCH allocations in the measurement period due to lack of GSL devices in one GPH RP. Note that a move of a cell to a new GPH RP (perhaps with spare capacity) is usually initiated after this counter has stepped. Note: Please note that this counter are not recommendable to use for PS resource utilization as it is affected by code changes between projects. To determine PCU/GSL device allocation failure rate, please use the following counters/formula instead: 100*ALLPDCHPCUFAIL/ALLPDCHPCUATT [%] 216/1553-HSC 103 12/16 Uen E | 2010-11-10 171 User Description, Radio Network Statistics AQMDELIVDATA Total amount of data delivered by AQM in kbit. AQMRECDATA Total amount of data received by AQM in kbit. FAILMOVECELL Number of times an attempt to move a cell from one GPH RP to another has failed. Move of cells can be initiated due to lack of GSL devices or high GPH processor load. Failure to move of cell due to high GPH processor load can also be monitored by a separate counter LCCELLMOVREJ, see Section 6.17.12 on page 187. When the FAILMOVECELL counter begins to step, and it is not due to high GPH processor loadd, it indicates a lack of GSL devices in the entire PCU. Consider that some GSL devices may be reserved for use as on-demand PDCH by parameter setting. DISCDL Discarded PCU frames per PCU on the downlink. See Reference [1] for details. DISCUL Discarded PCU frames per PCU on the uplink. See Reference [1] for details. PAGCSBSC Number of 48.018 PAGING CS messages (arriving at the BSC from the SGSN) with paging area including more than one cell. PAGCSCONG Number of 48.018 PAGING CS messages (arriving at the BSC from the SGSN) rejected due to congestion in the CP. PAGPSBSC Number of 48.018 PAGING PS messages (arriving at the BSC from the SGSN) with paging area including more than one cell. NACCPCO The counter NACCPCO is incremented each time the PACKET CELL CHANGE ORDER message is sent to the MS due to an MS initiated NACC procedure NC2ORDER The number of times per BSC that MSs were ordered to NC2 and remained in NC2 long enough to be given the opportunity to send at least one 44.060 PACKET MEASUREMENT REPORT message. NC2CONF The number of times per BSC that MSs have sent at least one 44.060 PACKET MEASUREMENT REPORT message after being ordered to enter NC2. NC2PCO The number of 44.060 PACKET CELL CHANGE ORDER messages sent per BSC while the MS was in NC2. The counter NACCPCO is not affected. The PCU device allocation failure rate can be calculated as: 172 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring PCUallfail = ALLP DCHP CUF AIL 3 100 [%] ALLP DCHP CUAT T Equation 80 PCU Device Allocation Failure Rate 6.17.6 Counters for Qos Feature on BSS Level 6.17.6.1 Introduction The main objective of these measures is to allow the operator to check that their QoS parameter settings result in the system sharing resources in the desired way. Note that the overall performance for the “IP throughput” on a BSC level should be obtained by summation of the cell level counters, these BSC level counters should NOT be used since they are calculated using a slightly different method. 6.17.6.2 Object Types and Counters Object type: BSCQOS Title: GPRS Quality of Service counters per BSC. NUMBERTBF The accumulated total number of data transfers or periods of PFC activity for a given combination of GPRS/EGPRS, Uplink/Downlink, RLC Ack/Unacknowledeged mode, MaximumBitrate[8 values: 20, 40, 60, 80, 100, 120, 140, 160 for GPRS; 60, 120, 180, 240, 300, 360, 420, 480 for EGPRS] and QoS class[THP1,THP2,THP3, Background]. Units: integer NUMBERLLCPDU The accumulation of the amount of transmitted LLC PDU data for all data transfers for a given combination of GPRS/EGPRS, Uplink/Downlink, RLC Ack/Unacknowledeged mode, MaximumBitrate[8 values: 20, 40, 60, 80, 100, 120, 140, 160 for GPRS; 60, 120, 180, 240, 300, 360, 420, 480 for EGPRS] and QoS class[THP1,THP2,THP3, Background]. Units: kbit PFCLIFETIME The accumulation of the lifetimes of all data transfers for a given combination of GPRS/EGPRS, Uplink/Downlink, RLC Ack/Unacknowledeged mode, MaximumBitrate[8 values: 20, 40, 60, 80, 100, 120, 140, 160 for GPRS; 60, 120, 180, 240, 300, 360, 420, 480 for EGPRS] and QoS class[THP1,THP2,THP3, Background]. Units: seconds 216/1553-HSC 103 12/16 Uen E | 2010-11-10 173 User Description, Radio Network Statistics Up to two hundred records can exist related to the object type BSCQOS, one for each possible combination of characteristics. Each of these records has one data field which contains a number that uniquely identifies this combination. There is a translation table QOSTRANTAB that relates the numeric code in the data field to a specific combination of characteristics. The remaining data fields in each record contain the values for the three counters described above. 6.17.6.3 Description The counters work in a similar way to the cell level counters described in Section 6.3 on page 99. The major difference is that the total data sent for each combination of characteristics and the time it took to send this is just summed over the measurement period. If the QoS feature is switched off then only the background class counters are used. The Maximum Bit Rate (MBR) does not apply for the background QoS class. This means there are (2*2*2*3*8) + (2*2*2*1) = 200 possible combinations of characteristics and therefore 600 new counters are required per BSC for the three separate measures. 6.17.6.4 Suggested Formulae BQoSThr = NUMBERLLCPDU PFCLIFETIME [kbit=s] Equation 81 Average LLC Throughput for All Data Transfers (One Combination of Characteristics) During the Measurement Period BQoSData = NUMBERLLCPDU NUMBERTBF [kbit] Equation 82 Average LLC Throughput for All Data Transfers (One Combination of Characteristics) During the Measurement Period The total number of data transfers or periods of PFC activity (with a specific combination of characteristics) is given directly by the relevant NUMBERTBF counter. There can be more than one data transfer per TBF due to the TBF keep alive mechanisms. Note that only the raw counter values are output from STS. However, reports defined in the NWS/ENIQ applications of OSS display these in a set of easy to interpret tables. 6.17.7 Counters for TBF Keep Alive Mechanisms The counters below can be used to tune the parameters related to the TBF keep alive mechanisms. Note that the features are triggered for some GMM/SM signalling and heartbeat messages for e-mail devices that typically end before receiving further data from the SGSN. So the absolute value for the “success” 174 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring rates are not so important — but the relative improvement when the parameters related to the timers are changed. Object type: BSCGPRS Title: TBF keep alive mechanisms, 6 counters per BSC (subset of all counters in object type). 6.17.8 ESUDLTBF Total number of TBFs that were setup in “Early setup of DL TBF” mode. ESUTONORM Number of TBFs in “Early setup of DL TBF” mode that receive data from SGSN before ESDELAY timer expires. DELRELDLTBF Total number of TBFs for which the release is delayed by the “Delayed Release of DL TBF mode” feature. DELRELTONRM Number of TBFs in “Delayed Release of DL TBF mode” that receive data from SGSN before DLDELAY timer expires. EXULTIP Number of TBFs that enter “temporary inactive period” (Extended Uplink TBF mode). EXULNRM Number of TBFs entering “temporary inactive period” that receive “real” data from the MS before ULDELAY timer expires. Additional Counters for Streaming The counters below can be used to tune the parameters related to the streaming TBF keep alive mechanisms: Object type: DELSTRTBF Title: TBF keep alive mechanisms for streaming, 4 counters per BSC. STARTSTRTBF Total number of times TSTREAMSTART has been triggered. STARTCONTSTRTBF Number of times a streaming TBF continues after TSTREAMSTART has been triggered. PENDSTRTBF Total number of times TSTREAMPENDING has been triggered. PENDCONTSTRTBF Number of times a streaming TBF continues after TSTREAMPENDING has been triggered. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 175 User Description, Radio Network Statistics 6.17.9 Counters for Flexible Abis The counters below are used for to monitor the Abis utilisation if Flexible Abis is used, for more information see Reference [17]. Object type: CELLFLXAB Title: 7 counters for flexibly allocated Abis paths per cell. FLX16ATT The counter is incremented by one for every attempt to allocate a 16 kbps flexibly allocated Abis path. The counter is also incremented by one when 64 kbps Abis path was requested but 16 kbps was allocated. An attempt is made when a TCH with flexibly allocated Abis path has been allocated at the following situations: — The allocation is for an on-demand Packet Switch (PS) connection with 16 kbps flexibly allocated Abis path – 16 kbps flexibly allocated Abis paths is requested for a semi dedicated Packet Data Channel (PDCH) — The allocation is for an on-demand Packet Switch (PS) connection with 64 kbps flexibly allocated Abis path but 16 kbps was allocated – 64 kbps flexibly allocated Abis paths is requested for a semi dedicated Packet Data Channel (PDCH) but 16 kbps was allocated. Note: FLX16SUCC The counter will step double when a half rate connection is used. The counter is incremented by one for every successful allocation of 16 kbps flexibly allocated Abis path for PS connections. The allocation will be successful if there are available Abis paths in the pool of 16 or 64 kbps Abis paths for PS connections. Note: The counter will step double when a half rate connection is used. FLX64ATT Number of allocation attempts of a 64 kbps Abis path. FLX64SUCC Number of successful allocations of a 64 kbps Abis path. FLXCS16ATT Number of attempts to allocate a 16k Abis path for CS. FLXCS16SUCC Number of successful allocations of a 16k Abis path for CS. FLX8SUCC Number of successful allocations for an AMR FR using a 8 kbit/s Abis path. Regarding the CS Abis path allocations, it should be noticed that the ratio of number of successful allocations of a 16k Abis path to number of attempts for 176 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring allocation of a 16k Abis path (i.e. FLXCS16SUCC/FLXCS16ATT) does not reflect the subscriber perceived congestion in 16k Abis paths since for each CS call connection setup a maximum of 8 attempts for allocation of a 16k Abis path are done. In the object type CELLGPRS3 there are two counter for PDCH preemptions due to Abis congestion. Object type: CELLGPRS3 Title: 2 counters for PDCH preemptions due to Abis congestion per cell. PMTCSABCONG Number of CS initiated preemptions of Abis path done either by preemption of an idle PDCH or by downgrading of a E-PDCH not carrying any EGPRS traffic from E-PDCH to B-PDCH. Flexible on-demand and semi-dedicated PDCHs on the same TG as the originating TS are effected. If it was not possible to free any Abis resources in this way, the ordinary procedure for preemption will take over. Preemptions will in that case be included in the counters PREEMPTPDCH and possibly PREEMTPDCHSUB, but PMTCSABCONG will not be stepped. PMTPSABCONG Number of PS initiated preemptions of Abis path done either by preemption of an idle PDCH or by downgrading of a E-PDCH not carrying any EGPRS traffic from E-PDCH to B-PDCH. Flexible on-demand and semi-dedicated PDCHs on the same TG as the originating TS are effected. In the object types RES64K and NONKRES64K there are counters for status of Abis paths, separate for the 64K and non–64K pools. Object type: RES64K Title: 4 counters showing status of the 64KRES pool of Abis paths per TG. MIN64K Minimum number of idle 64 kbps Abis paths in 64K pool during last 15 minutes, calculated from samples taken every minute. MAX64K Maximum number of idle 64 kbps Abis paths in 64K pool during last 15 minutes, calculated from samples taken every minute. AVG64K Average number of idle 64 kbps Abis paths in 64K pool during last 15 minutes, calculated from samples taken every minute. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 177 User Description, Radio Network Statistics FRAG64K Fragmentation level of the 64K pool, i.e. the number of fragmented (partly used) 64 kbps Abis paths in the 64K pool. Object type: NONRES64K Title: Counters showing status of the non–64KRES pool of Abis paths per TG. MIN16K Minimum number of idle 16 kbps Abis paths in non-64K pool during last 15 minutes, calculated from samples taken every minute. MAX16K Maximum number of idle 16 kbps Abis paths in non–64K pool during last 15 minutes, calculated from samples taken every minute. AVG16K Average number of idle 16 kbps Abis paths in non–64K pool during last 15 minutes, calculated from samples taken every minute. The TG level counters above both for the 64KRES and non-64KRES pools of Abis path give an indication of the Abis resource situation within the TG. As an example, we have a lack of Abis path resources within the non-64KRES pool in the TG if the counter MIN16K has a value of zero and the value of AVG16K is very low. Similarly, a lack of Abis path resources within the 64KRES pool in the TG is valid if the counter MIN64K has a value of zero and the value of AVG64K is very low. In object type CLRATECHG there counters for intra cell handover due to FR to HR channel rate change due to Abis congestion. Object type: CLRATECHG Title: Two counters for intra cell handover due to FR to HR channel rate change due to Abis congestion. AMRABHOSUCFRHR Number of successful intra cell handovers due to FR to HR channel rate change at Abis congestion made by an made by a mobile capable of AMR Narrowband, but not capable of AMR Wideband. AWABHOSUCFRHR Number of successful intra cell handovers due to FR to HR channel rate change at Abis congestion made by an AMR wideband capable mobile. NAMRABHOSUCFRHR Number of successful intra cell handovers due to FR to HR channel rate change made at Abis congestion by a mobile not capable of AMR. 178 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6.17.10 Additional Counters for DTM 6.17.10.1 Introduction Counters for monitoring of some main PS performance indicators for DTM connections are available. The objective is to be able to monitor these indicators separately for packet transfers being performed on its own (see Section 6.2 on page 96, Section 6.3 on page 99, Section 6.4 on page 108, and Section 6.10 on page 138) and for packet transfers being performed simultaneously with a CS connection by use of DTM. Since the need for coordination of the CS and PS channels might make it harder to achieve the best possible PS channels for DTM connections this separation is necessary. 6.17.10.2 Object Types and Counters The object type CLDTMQOS contains 10 per cell counters to monitor the average throughput of LLC-PDUs per active PFC and the total amount of LLC-PDU data for DTM connections Note that the counters for streaming exclude EIT, while the other data volume counters and the throughput counters include traffic classes Background and Interactive. DTMGULTHP Accumulated weighted throughput (throughput * datavolume) for LLC PDUs per TPF UL. Counts for traffic classes background and interactive, MSs in DTM and GPRS mode TBFs. With Flexible Abis the counter value will be slightly lower. Unit: kb*kbps DTMGDLTHP Accumulated weighted throughput (throughput * datavolume) for LLC PDUs per TPF DL. Counts for traffic classes background and interactive, MSs in DTM and GPRS mode TBFs. With Flexible Abis the counter value will be slightly lower. Unit: kb*kbps DTMEGULTHP Accumulated weighted throughput (throughput * datavolume) for LLC PDUs per TPF UL. Counts for traffic classes background and interactive, MSs in DTM and EGPRS mode TBFs. With Flexible Abis the counter value will be slightly lower. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 179 User Description, Radio Network Statistics Unit: kb*kbps DTMEGDLTHP Accumulated weighted throughput (throughput * datavolume) for LLC PDUs per TPF DL. Counts for traffic classes background and interactive, MSs in DTM and EGPRS mode TBFs. With Flexible Abis the counter value will be slightly lower. Unit: kb*kbps DTMULGDATA Accumulated LLC PDU data volume UL per TPF. Counts for traffic classes background and interactive, MSs in DTM and GPRS mode TBFs. Unit: kb DTMDLGDATA Accumulated LLC PDU data volume DL per TPF. Counts for traffic classes background and interactive, MSs in DTM and GPRS mode TBFs. Unit: kb DTMULEGDATA Accumulated LLC PDU data volume UL per TPF. Counts for traffic classes background and interactive, MSs in DTM and EGPRS mode TBFs. Unit: kb DTMDLEGDATA Accumulated LLC PDU data volume DL per TPF. Counts for traffic classes background and interactive, MSs in DTM and EGPRS mode TBFs. Unit: kb DTMULSTRDATA Accumulated LLC PDU data volume UL per TPF. Counts for traffic class streaming (EIT excluded), MSs in DTM and EGPRS/GPRS mode TBFs. Unit: kb DTMDLSTRDATA Accumulated LLC PDU data volume DL per TPF. Counts for traffic class streaming (EIT excluded), MSs in DTM and EGPRS/GPRS mode TBFs. Unit: kb The object type CLDTMPER contains 15 per cell counters to monitor the average number of reserved PDCHs for DTM TBFs compared to the maximum possible PDCHs for the multislot class regardless of the TBF mode in both 180 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring UL and DL. It also gives statistics about DL IP buffer discards and UL accessibility/retainability for DTM connections. Note: To allow better correlations with the throughput counters the counters DTMDLTBFSCAN, DTMULTBFSCAN, DTMDLMUTIL, DTMULMUTIL, DTMDLMAXTS and DTMULMAXTS are only stepped for TBFs that are actively engaged in the transfer of interactive or background user data and exclude small transfers with a buffer size less than 500 bytes (DL only). This means that the following TBFs are excluded: • TBFs in keep alive mode sending dummy data • TBFs used for the Streaming traffic class • TBFs used for GMM/SM signalling DTMDLTBFSCAN Number of DL DTM TBFs in modes BASIC, GPRS and EGPRS scanned during the measurement period. DTMULTBFSCAN Number of UL DTM TBFs in modes BASIC, GPRS and EGPRS scanned during the measurement period. DTMDLMUTIL Accumulation of the precentage of number of timeslots actually reserved vs. maximum number of timeslots possible for the MS to reserve, calculated for every DL DTM TBF in modes BASIC, GPRS or EGPRS scanned. DTMULMUTIL Accumulation of the precentage of number of timeslots actually reserved vs. maximum number of timeslots possible for the MS to reserve, calculated for every UL DTM TBF in modes BASIC, GPRS or EGPRS scanned. DTMDLMAXTS The accumulation of the maximum possible reservable timeslots DL for DTM TBFs DTMULMAXTS The accumulation of the maximum possible reservable timeslots UL for DTM TBFs DTMTFILDIS Total number of times the entire contents of the downlink LLC PDU buffer was discarded due to the reason, “No available PDCH or TFI” for DTM TBFs DTMRRLDIS Total number of times the entire contents of the downlink LLC PDU buffer was discarded due to radio reasons for DTM TBFs DTMOTHLDIS Total number of times the entire contents of the downlink LLC PDU buffer was discarded due to any other reason than no available PDCH/TFI or radio reasons for DTM TBFs. DTMULSUCRES Total number of successful setups of uplink TBFs when the MS is in Dedicated mode or DTM. It is incremented 216/1553-HSC 103 12/16 Uen E | 2010-11-10 181 User Description, Radio Network Statistics when the assignment message has been sent to the MS and the USF scheduling has started. DTMULTFIFAILRES Total number of failed UL reservations for the reason “No PDCH, USF or TFI” as a result of the message DTM REQUEST or as a result of failed UL reservations while the MS is in DTM DTMULOTHFAILRES Total number of 44.060 PACKET ACCESS REJECT and 44.018 DTM REJECT sent to the MS during TBF establishment for any other reason than “No PDCH, no USF, no TFI or Abis Overload”, when the MS is in Dedicated mode or DTM. DTMULABISFAILRES The counter DTMULABISFAILRES counts the number of 44.060 PACKET ACCESS REJECT and 44.018 DTM REJECT sent to the MS during TBF establishment for the reason “Abis Overload”, when the MS is in Dedicated mode or DTM. Note: DTMULRELLOST The indicator for Abis Overload is valid when using Abis over IP or Abis Optimization. Total number of times that an established uplink TBF is released because of lost radio contact with the MS, when the MS is in Dual Transfer Mode. DTMPREEMPTULREL The total number of times that an established uplink TBF is released due to PDCH preemption, when the MS is in Dual Transfer Mode. DTMOTHULREL The total number of times an established uplink TBF is abnormally released due to other reasons than preemption or radio contact lost, when the MS is in Dual Transfer Mode. MSESTULDTMTBF Number established uplink DTM TBFs were the MS has started to send data and at least one RLC block has been received by the BSC. 182 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Note: The throughput counters, DTMGULTHP, DTMDLTHP, DTMEGULTHP and DTMEGDLTHP, are affected by the interrupt that occurs when PDCHs are up- or downgraded. Since an EGPRS mobile is sometimes reserved on E-PDCHs even if B-PDCHs give better throughput, these counter values will not be comparable with the counter values received when Flexible Abis is not activated. This is because the mobile will not be able to receive the maximum number of PDCHs that it can handle, i.e. according to the multislot class and the number of E-PDCHs is limited. 6.17.10.3 Description The counters in object type CLDTMQOS are similar to the ones in object type CELLGPRS4, CELLQOSG, CELLQOSEG and CELLQOSS, see Section 6.3 on page 99. The counters in CLDTMQOS are not separated for all different QoS classes and they are separated for GPRS/EGPRS capable MSs as the counters in the object type CELLGPRS4. The counters in object type CLDTMPER is similar to the ones in object type CELLGPRS2, see Section 6.6 on page 116. and Section 6.5 on page 113, and in object type TRAFFGPRS2, see Section 6.13 on page 153. The difference is for the multislot usage counters that there is no separation for different TBF modes, and that there are no separate counters for each combination of number of reserved timeslots out of possible reservable timeslots. The DL IP buffer discards and UL accessibility/retainability counters are stepped for somewhat different reasons. All counters only contain data sent during DTM. 6.17.10.4 Suggested Formulae The percentage of the failed DTM UL establishment requests can be calculated as: DTMULTFIFAILRES + DTMULOTHFAILRES DTMulfail = DTMULSUCRES + DTMULTFIFAILRES + DTMULOTHRAILRES 3 100 [%] Equation 83 Percentage of the Failed DTM UL Establishment Requests The average number of maximum possible timeslots that were reservable by mobiles on the downlink is given by: DTMDLMAXTS DTMdlMUTILmax = DTMDLTBFSCAN Equation 84 Average Number of Maximum Possible Timeslots that Were Reservable by Mobiles on the Downlink The average utilisation of those timeslots is given by: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 183 User Description, Radio Network Statistics DTMDLMUTIL 3 100 [%] DTMdlPSmutilALL = DTMDLTBFSCAN Equation 85 Average Utilisation of Timeslots 6.17.11 Counters for Ericsson Instant Talk (EIT) 6.17.11.1 Introduction The features EIT Performance and Admission Control for EIT improves the ability for GPRS/EGPRS to be used as a bearer for the new application EIT, Ericsson Instant Talk over a Streaming bearer. EIT is a kind of Walkie-talkie service over GPRS (and WCDMA) and may be characterized as a voice over IP application. The delay requirements for PTT are more relaxed than e.g. ordinary speech but more stringent than for Streaming of video or audio clips. The counters can be used to monitor the quality of the EIT traffic and to give a hint what is the source to the bad quality; number of EIT TBFs, resources per EIT TBF, radio link quality etc. With the introduction of Admission Control, only the traffic that get EIT Streaming priority will contribute to the below described counters. More information about EIT admission control can be found in Reference [22]. 6.17.11.2 Object Types and Counters The object type CELLEIT contains 21 per cell counters for measure of the performance of EIT with respect to the Push-To-Talk service. 184 Q1TDDLEIT Total number of DL TBFs where the percentage of LLC-PDUs that achieved the QoS attribute transfer delay (or better) in the TBF was 80% or less. Q2TDDLEIT Total number of DL TBFs where the percentage of LLC-PDUs that achieved the QoS attribute transfer delay (or better) in the TBF was between 81% and 95%. Q3TDDLEIT Total number of DL TBFs where the percentage of LLC-PDUs that achieved the QoS attribute transfer delay (or better) in the TBF was between 96% and 100%. Q1TDULEIT Total number of UL TBFs where the percentage of LLC-PDUs that achieved the QoS attribute transfer delay (or better) in the TBF was 80% or less. Q2TDULEIT Total number of UL TBFs where the percentage of LLC-PDUs that achieved the QoS attribute transfer delay (or better) in the TBF was between 81% and 95%. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring Q3TDULEIT Total number of UL TBFs where the percentage of LLC-PDUs that achieved the QoS attribute transfer delay (or better) in the TBF was between 96% and 100%. EITDLGTBF Number of DL EIT streaming TBFs in modes BASIC and GPRS. EITULGTBF Number of UL EIT streaming TBFs in modes BASIC and GPRS. EITDLETBF Number of DL EIT streaming TBFs in mode EGPRS. EITULETBF Number of UL EIT streaming TBFs in mode EGPRS. EITTBFSCAN Total number of scans for counting PDCHs and TBFs for EIT. RLCGDLEITSCHED Number of EIT GPRS RLC blocks scheduled DL, both first time and re-transmission. Dummy and control blocks excluded. RLCGULEITSCHED Number of EIT GPRS RLC blocks scheduled UL, both first time and re-transmission. Dummy and control blocks excluded. RLCEDLEITSCHED Number of EIT EGPRS RLC blocks scheduled DL, both first time and re-transmission. Dummy and control blocks excluded. RLCEULEITSCHED Number of EIT EGPRS RLC blocks scheduled UL, both first time and re-transmission. Dummy and control blocks excluded. EITDLGPDCH Number of PDCHs carried at least one EIT TBF of mode GPRS, DL. EITULGPDCH Number of PDCHs carried at least one EIT TBF of mode GPRS, UL. EITDLEPDCH Number of PDCHs carried at least one EIT TBF of mode EGPRS, DL. EITULEPDCH Number of PDCHs carried at least one EIT TBF of mode EGPRS, UL. EITDLBPDCH Number of PDCHs carried at least one EIT TBF of mode BASIC, DL. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 185 User Description, Radio Network Statistics EITULBPDCH Number of PDCHs carried at least one EIT TBF of mode BASIC, UL. The object type CELLEIT2 contains 8 per cell counters for measure of the performance of EIT with respect to the Push-To-Talk service. RLCGDLVOLEIT Payload data in GPRS RLC blocks scheduled for EIT, DL. Only first time. Re-transmitted, dummy and control blocks excluded. Unit: bits RLCGULVOLEIT Payload data in GPRS RLC blocks scheduled for EIT, UL. Only first time. Re-transmitted, dummy and control blocks excluded. Unit: bits RLCEDLVOLEIT Payload data in EGPRS RLC blocks scheduled for EIT, DL. Only first time. Re-transmitted, dummy and control blocks excluded. Unit: bits RLCEULVOLEIT Payload data in EGPRS RLC blocks scheduled for EIT, UL. Only first time. Re-transmitted, dummy and control blocks excluded. Unit: bits LLCVOLDLEIT Volume data in LLC blocks sent for EIT, DL. Unit: bits LLCVOLULEIT Volume data in LLC blocks sent for EIT, UL. Unit: bits 186 ACREQEIT Total number of requests for TBFs to be admitted with EIT priority. The counter is stepped for every data burst (TPF) that is requested to be transferred with EIT Streaming priority ACREJEIT Total number of times admission was rejected. The counter is stepped every time an EIT data burst (TPF) cannot be transferred according to the requested EIT priority 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring 6.17.11.3 Suggested Formulae The following formula can be used to calculate the EIT admittance ratio. This will give an indication of how well the system is dimensioned, given the current EIT traffic intensity. 0 ACREJEIT ) 3 100 [%] EITaccSucc = (ACREQEIT ACREQEIT Equation 86 EIT Admittance Rate The following formula can be used to calculate the percentage of EIT TBFs where more than 96% of the LLC-PDUs achieved the QOS attribute transfer delay for the uplink ( a similar formula can be created for the downlink). This will give an indication of the quality of EIT from the end-user perspective. Q3TDULEIT EITulSucc = (Q1TDULEIT + Q 2T DULEIT + Q3TDULEIT ) 3 100 [%] Equation 87 Transfer Delay Success, UL. 6.17.12 PCU Load Control 6.17.12.1 Introduction The Load Control feature increases the PCU capacity in the terms of more effective use of the resources, which makes the utilization of the hardware to an optimum considering the CPU load. The feature also strives for a balanced load and increases the robustness of the PCU. The load Control feature is divided into the areas Load Regulation, Load Distribution and Overload Protection. The load regulation dynamically regulates non-critical software to use just as much of the CPU that it does not interfere with the critical processes. No STS counters are stepped by this function. The CPU load in different RP's changes randomly depending on the users activity. The benefit from Load Distribution is that the traffic load is dynamically distributed between RP's, which will increase the overall capacity for a larger PCU node. The Load Distribution function is a fairly slow regulating function and prevents the PCU from being load regulated or overload protected during longer intervals. The load is distributed by move of handling of cells and a move of handling of a cell is triggered either by an uneven distribution of the load or when an RP is overloaded. The Load Distribution function continuously monitors the individual load of each RP and compares it with the other RPs within the PCU. If a certain RP is extremely loaded, and at the same time there are RPs with much less load, then a Move of Cell is triggered. RPs beneath a defined CPU load level are treated as target candidates for a cell move. When a cell move attempt is successful the STS counter LCCELLMOV is stepped by one. If an attempt to move a cell because of RP overload fails, due to that no suitable target RPs are found the STS counter LCCELLMOVREJ is stepped by one. The counters MOVECELLTBF, CELLMOVED and FAILMOVECELL 216/1553-HSC 103 12/16 Uen E | 2010-11-10 187 User Description, Radio Network Statistics described in chapters Section 6.17.2 on page 166 and Section 6.17.5 on page 171 are also stepped for cell move intiated by the PCU Load Distribution. The STS counter LCHIRPPLOAD is stepped each minute when more than 2% of all Channel Requests are rejected due to load regulation or overload protection. The counter LCLRPARREJ in Object Type GPHLOADREG shows the accumulated the number of rejected Packet Access Requests due to high CPU load in the GPH. When the Overload Protection mechanism detects a risk for lack of memory the first action is to reduce the bucket size for all MSs in the next flow control message. This will reduce the buffer sizes and will have a negative effect on the throughput in the system. The STS counter LCMSSUPRFC is stepped once every 20 seconds as long as this action is in use. If the memory situation becomes even worse the next action is to prevent MSs to set up any new uplink connections. This is done by rejecting packet access requests, which are received in a `Channel Request', `Packet Channel Request', or `EGPRS Packet Channel Request' message. The concerned MS is not allowed to do any new packet access requests in the same cell for at least 30 seconds. The STS counter LCPARREJ is stepped once for every rejected packet access request, the counter PREJOTH, see Section 6.6 on page 116, is also stepped in these cases. 6.17.12.2 Object Types and Counters The object type GPHLOADREG contains counters to monitor the PCU Load Control. 188 LCCELLMOV Number of succeeded cell move attempts by PCU Load Control. LCCELLMOVREJ Number of failed cell move attempts by PCU Load Control due to lack of GPH RP candidates with low load (only valid for forced move of cell). LCHIRPPLOAD Accumulated number of minutes where more than 2% of all Channel Requests are rejected due to load regulation or overload protection. LCLRPARREJ The accumulated number of rejected Packet Access Requests due to high CPU load in the GPH. LCPARREJ Number of rejected Packet Access Request per BSC due to lack of GPH RP memory. LCMSSUPRFC The time when MS Flow Control has been sent with a reduced bucket size due to lack of PCU-RP memory. The counter is increased by one every 20th second as long as this action is in use. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Performance Monitoring LCRELBUSYHI3 Not used. LCRELIDLEHI3 Not used. Please, also note that the following counter in object type CELLGPRS3 is not used any longer. LCCLRELBUSYHI3 Not used. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 189 User Description, Radio Network Statistics 190 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters 7 Abis over IP and Abis Optimization Measurements and Counters In order to supervise the packet Abis features (see Reference [37] and Reference [38], respectively) as a “black box” it is recommended to look at the total frame loss ratio and total delay. These measures are the most important to track for packet Abis as speech quality, throughput and latency will be affected by frame loss and delay on packet Abis. Note: 7.1 Abis Local Connectivity (ALC) introduced in BSS 08A changes the traffic pattern on Abis as all traffic present on Abis Lower do not need to be present on Abis Upper. This impacts several counters on Abis Upper as they will only show part of the total traffic from a RBS. In the following sections, counters and formulas affected by ALC will have a note regarding this issue and a reference to the User Description, Abis Local Connectivity, Reference [43], where details about the ALC impact on a particular counter can be found. Using ALC means that the amount of traffic sent on Abis Lower does not directly correspond to the amount of traffic sent on Abis Upper. This means that it is not really meaningful to calculate KPIs for the entire Abis path from the BSC to the BTS. The KPI formulas “Downlink frame loss ratio per TG for Abis over IP CS traffic”, "Uplink frame loss ratio per TG for Abis over IP PS traffic” and “Downlink frame loss ratio per TG for Abis over IP PS traffic” will however give reasonable values and can be used to monitor Abis performance from a general perspective. Frame Loss Ratio Formulas for Packet Abis Frame loss will occur in a number of places in the packet Abis system: • In super channel buffers in BTS and BSC, when congestion on the super channel occurs. • By IP shaping and policing in STN and BSC, to prevent congestion on the Abis Upper link. • In jitter buffers in BSC and BTS, when packets arrive too late. • On the Abis Upper transmission link, due to congestion or bit errors. In all these parts of packet Abis the frame loss is counted in the packet Abis system, but please note that these detailed measurements are described in Reference [39] and Reference [37], respectively, while in this document only formulas for the total frame loss ratio for the packet Abis system are treated. For voice traffic, the acceptable frame loss rate depends on the codec in use but is typically in the 0.5-1% range mouth-to-ear. In order to achieve this, the total loss rate on Abis should be below 0.1 % since most of the losses are expected in the air interface. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 191 User Description, Radio Network Statistics The total frame loss ratio for Abis Optimization and Abis over IP in the uplink and downlink direction can be calculated as shown in Equation 88 - Equation 89. The corresponding formulas separated in CS and PS are shown in Equation 90 - Equation 93, respectively. The counters used in the formulas are explained in Section 7.5 on page 206 Object type: SUPERCH ULFramePktLoss = Equation 88 Total frame loss ratio per Super Channel UL for Abis Optimization and Abis over IP DLF rameP ktLoss = Equation 89 LOST ULP ACK 3 100 [%] T OT ULP SSCFRBUF + T OT F RULSCBUF LOST DLP ACK 3 100 [%] T OT DLP SSCF RBUF + T OT F RDLSCBUF Total frame loss ratio per Super Channel DL for Abis Optimization and Abis over IP The total frame loss ratio for Abis over IP in the uplink and downlink direction can be calculated as shown in formulas Equation 88 - Equation 89. In is also possible to separate the Frame Loss in CS and PS by using the formulas Equation 90 - Equation 93. ULCSF rameLoss = Equation 90 Note: Total CS traffic frame loss ratio per Super Channel UL for Abis Optimization and Abis over IP. N.B! this formulas will not give a correct value when the Abis Local Connectivity is used. For details, please, see the User Description, Abis Local Connectivity, Reference [43]. DLcsFrameLoss = Equation 91 F CSLOST DL 3 100 [%] T OT F RDLSCBUF Total CS traffic frame loss ratio per Super Channel DL for Abis Optimization and Abis over IP ULP SF rameLoss = Equation 92 Equation 93 F P SLOST UL 3 100 [%] T OT ULP SSCF RBUF Total PS traffic frame loss ratio per Super Channel UL for Abis Optimization and Abis over IP DLP SF rameLoss = 192 F CSLOST UL 3 100 [%] T OT F RULSCBUF F P SLOST DL 3 100 [%] T OT DLP SSCF RBUF Total PS traffic frame loss ratio per Super Channel DL for Abis Optimization and Abis over IP 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters 7.2 Delay measurements Formulas for Packet Abis Delay may occur in a number of places in the packet Abis link: • In super channel buffers in BTS and BSC, whenever congestion on the super channel occurs. • In bundling buffers in STN and BSC, to collect packets into bundles. • By IP shaping in STN and BSC to prevent congestion on the Abis Upper link. • In jitter buffers in BSC and BTS to restore inter-packet timing. • In the Abis Upper transmission link due to transmission delay or queuing in switches or routers. In all the packet Abis functions listed above packet delay is measured. Please note that these detailed measurements are described in Reference [37] and Reference [38], respectively, while in this document only formulas for the total delay for the packet Abis system are treated. The total delay for packet Abis can be separated for CS and PS traffic and is measured separately in uplink and downlink directions. Please see Equation 94- Equation 101 for detailed formulas for total packet Abis delay. T otDelayOptCSdl = Equation 94 Note: F SCBUF DELDL F SCBUF DLSCAN JBUF DELDL + FFJBUF [ms] DLSCAN Abis Optimization total delay per SC for CS traffic in the downlink direction. The formula above is only valid when using Abis optimization and not valid when using Abis over IP as the Super Channel buffer resides in STN when using Abis over IP. FSCBUFDELDL includes both CS and PS traffic frames but the delay in the Super Channel buffer is the same for both kinds of frames. The formula shown in Equation 94 is the sum of the delay in the super channel buffers in BSC and in the jitter buffers in BTS. In all normal cases this total delay is equal to the configured jitter buffer delay. FSCBUFDELUL includes both CS and PS traffic frames but the delay in the Super Channel buffer is the same for both kinds of frames. T otDelayOptCSdl = Equation 95 F SCBUF DELU L F SCBUF ULSCAN JBUF DELU L + FFJBUF [ms] ULSCAN Abis Optimization total delay per Super Channel for CS traffic in the uplink direction. The formula shown in Equation 95 is the sum of the delay in the super channel buffers in BSC and in the jitter buffers in BTS. In all normal cases this total delay is equal to the configured jitter buffer delay. The formula does not take Abis link delay into consideration. FSCBUFDELUL includes both CS and PS 216/1553-HSC 103 12/16 Uen E | 2010-11-10 193 User Description, Radio Network Statistics traffic frames but the delay in the Super Channel buffer is the same for both kinds of frames. T otDelayOptP Sdl = Equation 96 F SCBUF DELDL [ms] F SCBUF DLSCAN Abis Optimization total delay per SC for PS traffic in the downlink direction. Note: FSCBUFDELDL includes both CS and PS traffic frames but the delay in the Super Channel buffer is the same for both kinds of frames. Note: The formula above is only valid when using Abis optimization and not valid when using Abis over IP as the Super Channel buffer resides in STN when using Abis over IP. The formula in Equation 96 shows the PS traffic total delay downlink approximated by the delay in the Super Channel buffers in BSC. T otDelayOptP Sul = Equation 97 Note: F SCBUF DELU L [ms] F SCBUF ULSCAN Abis Optimization total delay per SC for PS traffic in the uplink direction. FSCBUFDELUL includes both CS and PS traffic frames but the delay in the Super Channel buffer is the same for both kinds of frames. The formula in Equation 97 shows the PS traffic total delay uplink, approximated by the delay in the Super Channel buffers in BSC. The formula does not take Abis link delay into consideration. T otDelayIP csDL = (BUNDG1AV EDEL=10) + IP delay=2 + X X F JBUF DELDL [ms] F JBUF DLSCAN W here : BUNDG1AV EDEL = average bundling delay CSSpeech SAP I = 10 IP delay (SIU counter) = P ingDelayAverage=10 [ms] F JBUF DELDL=F JBUF DLSCAN = average over all SC or W orst Case Equation 98 Abis over IP total delay per TG for CS traffic in the downlink direction. BUNDG1AVEDEL, IPdelay and the Summation of (FJBUFDELDL/FJBUFDLSCAN) are defined in the list below: Note: The formula above is only valid when using Abis over IP. IPdelay includes both CS and PS traffic frames but the delay is the same for both kinds of frames. The formula shown in Equation 98 is the sum of the bundling delay for speech (SAPI=10) in BSC (BUNDG1AVEDEL), the IP link delay (IPDELAY) and the jitter buffer delay in BTS (DLJITBUFAVDEL). The IP link delay is measured as roundtrip delay as it is not possible to measure the one-way delay between 194 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters BSC and STN. The IPDELAY is measured by sending ICMP ECHO REQUEST packets (also known as “ping” packets). The measurement assumes that the IP link delay of these packets is the same as the delay of the traffic packets. T otDelayIP psDL = (BUNDG3AV EDEL=10) + IP delay=2 [ms] W here : BUDG3AV EDEL = average bundling delay P S Data (SAP I IP delay (SIU counter) = P ingDelayAverage=10 [ms] Equation 99 = 12) Abis over IP total delay per TG for PS traffic in the downlink direction. BUNDG1AVEDEL and IPdelay are defined in the list below: • BUNDG1AVEDEL, shows the average bundling delay for CS speech traffic (SAPI=10) • IPdelay (STN counter for SIU) = PingDelayAverage/10 [ms] Note: PTA delay is not included in the formula above and the formula is only valid when using Abis over IP. IPdelay include both CS and PS traffic frames but the delay is the same for both kinds of frames. The formula shown in Equation 99 is the sum of the bundling delay for GPRS/EDGE traffic (SAPI=12) in BSC (BUNDG3AVEDEL) and the IP link delay (IPDELAY). The IP link delay is measured as roundtrip delay. The IP link delay is measured as roundtrip delay as it is not possible to measure the one-way delay between BSC and STN. The IPDELAY is calculated in different ways depending on the supported IWD of the STN node. The IPDELAY is measured by sending ICMP ECHO REQUEST packets (also known as “ping” packets). The measurement assumes that the IP link delay of these packets is the same as the delay of the traffic packets. X F JBUF DELU L [ms] T otDelayIP csUL = MCLT UL + IP delay=2 + F JBUF ULSCAN W here : MCLT UL = setting ofparameterMCLT UL (range0 0 20 [ms]) IP delay (SIU counter) = P ingDelayAverage=10 [ms] F JBUF DELU L=F JBUF ULSCAN = average over all SC or W orstCase X Equation 100 Abis over IP total delay per TG for CS traffic in the uplink direction. MCLTUL, IPdelay and the Summation of (FJBUFDELDL/FJBUFDLSCAN) are defined in the list below: • MCLTUL, is the setting of parameter MCLTUL (range 0-20 ms, default=1, recommended=5) • IPdelay (STN counter for SIU) = PingDelayAverage/10 [ms] • FJBUFDELDL/FJBUFDLSCAN shall either be averaged over all Super Channels or the worst case (SC) taken depending on investigation. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 195 User Description, Radio Network Statistics Note: The formula above is only valid when using Abis over IP. MCLTUL and IPdelay include both CS and PS traffic frames but the delay is the same for both kinds of frames. The formula shown in Equation 100 is the sum of the bundling delay in BSC (MCLTUL), the IP link delay (IPDELAY) and the jitter buffer delay in BSC (ULJITBUFAVDEL). The bundling delay is approximated with the configured maximum bundling delay. The actual delay is not measurable and can be lower, when the Abis link load is high. The IP link delay is measured as roundtrip delay as it is not possible to measure the one-way delay between BSC and STN.The IPDELAY is measured by sending ICMP ECHO REQUEST packets (also known as “ping” packets). The measurement assumes that the IP link delay of these packets is the same as the delay of the traffic packets. T otDelayIP psU L = MCLT UL + IP delay=2 [ms] W here : MCLT UL = setting ofparameterMCLT UL (range0 0 20 [ms]) IP delay (SIU counter) = P ingDelayAverage=10 [ms] Equation 101 Abis over IP total delay per TG for PS traffic in the uplink direction. MCLTUL and IPdelay are defined in the list below: • MCLTUL, is the setting of parameter MCLTUL (range 0-20 ms, default=1, recommended=5) • IPdelay (STN counter for SIU) = PingDelayAverage/10 [ms] Note: The formula above is only valid when using Abis over IP. MCLTUL and IPdelay include both CS and PS traffic frames but the delay is the same for both kinds of frames. The formula shown in Equation 101 is the sum of the bundling delay in BSC (MCLTUL) and the IP link delay (IPDELAY). The bundling delay is approximated with the configured maximum bundling delay. The actual delay is not measurable and can be lower, when the Abis link load is high. The IP link delay is measured as roundtrip delay as it is not possible to measure the one-way delay between BSC and STN. The IPDELAY is measured by sending ICMP ECHO REQUEST packets (also known as “ping” packets). The measurement assumes that the IP link delay of these packets is the same as the delay of the traffic packets. 7.3 Additional Measurements for Abis Optimization and Abis over IP If there is changes found in the supervision of total packet loss ratio or delay for Abis optimization or one suspect that the available resources are close to its limits, there are several useful measurements available. The following 196 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters measurements are recommended in order to isolate the reason for an observed change in total packet loss rate or delay : 7.3.1 • Abis Optimization Average and maximum Utilization [%] (Opt only) (UL, DL) • Abis over IP Average Utilization (IP only) [kbit/s] (UL, DL) • Abis over IP Average Throughput (IP only) [kbyte/s] (UL, DL) • Packet Abis Load • Packet Abis congestion (UL, CS) • Total packet Abis Jitter [ms] (UL, DL, CS, PS) • Rejected (due to overload) Call attempt ratio [%] Abis Optimization Average and Maximum Utilization Formulas for calculating Abis optimization average and maximum utilization are as shown in Equation 102 - Equation 105. The SCSIZE value in the formulas is the super channel size which is calculated by multiplying 'the number of defined Abis devices (64 kbit/s Abis timeslots) for the super channel' by 64000. ULabisUT IL = Equation 102 1000 3 8 3 KBREC KBSCAN 3 SCSIZE 3 100 [%] Average Abis Link Utilization UL. DLabisUT IL = 1000 3 8 3 KBSENT 3 100 [%] KBSCAN 3 SCSIZE 7.3.2 Equation 103 Average Abis Link Utilization DL. ULabisUT IL = 1000 3 8 3 KBMAXREC 3 100 [%] Equation 104 Maximum Abis Link Utilization UL. DLabisUT IL = 1000 3 8 3 KBMAXSENT 3 100 [%] SCSIZE Equation 105 Maximum Abis Link Utilization DL SCSIZE Abis over IP Average Utilization and Throughput For Abis over IP It is possible to calculate Abis average throughput and utilization uplink and downlink, respectively. The calculations are done using the formulas shown in Equation 106 - Equation 109. In addition to these formulas, there are also counters available for plotting histograms over the PGW - STN link utilization in the uplink and downlink directions, respectively, as described in Section 7.3.9 on page 204. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 197 User Description, Radio Network Statistics ULABISipAV Ethp = IP RECKBY T ES 3 8 [kbit=s] IP NUMSCAN Equation 106 Average Abis over IP uplink throughput measured on IP level during the measurement period. ULABISipAV Eutil = Equation 107 IP RECKBY T ES 3 8 3 100 [%] MBW UL 3 IP NUMSCAN Average Abis over IP utilization of available uplink bandwidth during the measurement period. MBWUL is the configured maximum available bandwidth in UL direction. The unit for MBWUL is kbps. DLABISipAV Ethp = IP SENT KBY T ES 3 8 [kbit=s] IP NUMSCAN Equation 108 Average Abis over IP downlink throughput measured on IP level during the measurement period. DLABISipAV Eutil = Equation 109 7.3.3 IP SENT KBY T ES 3 8 3 100 [%] MBW DL 3 IP NUMSCAN Average Abis over IP utilization of available downlink bandwidth during the measurement period. MBWDL is the configured maximum available bandwidth in UL direction. The unit for MBWDL is kbps. Overload handling for Packet Abis (Abis Optimization and Abis over IP) At overload on packet Abis reduction of PS traffic is done as a first step. If this isn't enough to remove the overload, reduction of CS traffic is done as a second step. The following counters will step during Abis overload for Abis over IP. These counters are on TG-level and IPOVLPSREG will normally be stepped prior to IPOVLCSREG. 198 IPOVLPSREG Indicates how long time the PS traffic reduction has been active for Abis over IP. Measured in seconds. Stepping of this counter indicates that a number of PS data scheduling has been omitted. IPOVLCSREG Indicates how long time the CS traffic reduction has been active for Abis over IP. Measured in seconds. Stepping of this counter indicates that almost all PS data scheduling has been omitted. Stepping of this counter also indicates a decreased level of new and existing CS calls. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters The following counters will step during Abis overload for Abis Optimization. These counters are on Super channel level and SCOVLPSREG will normally be stepped prior to SCOVLCSREG. 7.3.4 SCOVLPSREG Indicates how long time (in seconds) the PS traffic reduction has been active for Abis Optimization. Stepping of this counter indicates that a number of PS data scheduling has been omitted. SCOVLCSREG Indicates how long time (in seconds) the CS traffic reduction has been active for Abis Optimization. Stepping of this counter indicates that almost all PS data scheduling has been omitted. Stepping of this counter also indicates a decreased level of new and existing CS calls. Overload handling Abis over IP In order to check if there is a high overload situation on ABIS over IP and the feature 'IP Overload Robustness' is used, there are some counters of interest as listed below. For details about Abis over IP overload handling please see Reference [37]. IPOVLL1 This counter counts the number of seconds that actions to reduce severe overload have been initiated. Load reduction is in this case performed by completely removing PS traffic frames from the Abis interface, UL and DL. This is triggered by a high number (level 1 threshold) of RSL signalling (SAPI 0) retransmissions or OML signalling (SAPI 62) retransmissions on LAPD in the downlink, or when the CS-regulation functions have be active for a long time (45 seconds). For CS-regulation see Section 7.3.3 on page 198. Note: IPOVLL1 can be stepped even if the 'IP Overload Robustness' feature isn't active and the CS-regulation functions have been active for more than 45 seconds. IPOVLL2 This counter counts the number of seconds that actions to reduce severe overload have been initiated. Load reduction is in this case performed by completely removing both PS and CS traffic frames from the Abis interface, UL and DL. This is triggered by a high number (level 2 threshold) of RSL signalling (SAPI 0) retransmissions or OML signalling (SAPI 62) retransmissions on LAPD in the downlink. PSDISCOVL Indicates the number of discarded PS traffic frames DL at overload actions. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 199 User Description, Radio Network Statistics CSDISCOVL Indicates the number of discarded CS traffic frames DL at overload actions. Note: This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. The overload handling is active as long as the overload situation remains, which for Level 1 actions is typically in the order of 30 sec for PS data and for Level 2 actions typically 2 - 4 seconds for CS data, and is then terminated. In order to estimate the ratio of discarded CS and PS traffic frames, respectively, due to overload protection in the downlink direction, the following two formulas can be used: CSDISCOV L 3 100 [%] CSdiscFrameOvlDL = FRAMECOUNT Equation 110 Discarded CS traffic frames ratio DL at Abis over IP overload PSDISCOV L 3 100 [%] PSdiscFrameOvlDL = FRAMECOUNT Equation 111 7.3.5 Discarded PS traffic frames ratio DL at Abis over IP overload, where FRAMECOUNT=SUM over all SCs in TG: SIU counter SC_FramesDownlink Overload handling Abis Optimization In order to calculate the ratio for discarded frames due to overload handling when using Abis Optimization the following formulas can be used: ULP SSCBUFTHR + ULSCBUFT HR 3 100 [%] DiscOvlRatioUL = TOTFRULSCBUF + T OT ULP SSCFRBUF Equation 112 Discarded frames ratio (CS+PS) UL at Abis Optimization overload. DLCSSBUFT HR + DLPSSCBUFT HR 3 100 [%] DiscOvlRatioDL = T OT DLPSSCFRBUF + TOTFRDLSCBUF Equation 113 7.3.6 Discarded frames ratio (CS+PS) DL at Abis Optimization overload. TCH or TBF seizure rejects due to packet Abis Overload An important measure for CS calls related to packet Abis overload is to compare the number of times an attempt to seize a TCH (for CS) has been rejected due to packet Abis overload. The ratio of rejections as compared to assignment attempts can be estimated by the formula shown in Equation 114. 200 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters T CHRejectionRatio = Equation 114 OV ERLOADREJCON 3 100 [%] T F CALLS + T HCALLS Percentage of TCH seizure attempts (for CS) that failed due to Abis overload protection. OVERLOADREJCON This counter counts the number of new CS connections that were rejected due to Abis overload. The counter is stepped when an attempt to allocate an idle TCH fails, due to Abis overload. The counter is valid for the features Abis Optimization and Abis over IP. TFCALLS Number of channel allocation attempts for a TCH full rate channel. THCALLS Number of channel allocation attempts for a TCH half lrate channel Regarding PS, the ratio of UL TBF rejects due to congestion on packet Abis can be calculated using the formula shown in Equation 115. ULT BF RejRatio = Equation 115 7.3.7 P REJABISCONG 3 100 [%] P REJABISCONG + P REJT F I + P REJOT H + MSEST ULT BF Percentage of seizure attempts (for PS) that failed due to Abis overload protection. PREJABISCONG Description can be found at page Page 119 PREJTFI Description can be found at page Page 117 PREJOTH Description can be found at page Page 117 MSESTULTBF Description can be found at page Page 118 PGW-RP CPU Load The PGW-RP CPU Load measurements described below, are supported by STS counters, and thus possible to use in OSS. The operator is able to monitor the CPU load across all non-blocked PGW-RPs. Every 0,5 seconds, and for every PGW, one of the counters (depending on CPU load and if PGWB or GARP-2 is used) will have its value increased by one. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 201 User Description, Radio Network Statistics Object type: PGW Title: Counters for PGW load The following STS counters are used for PGWB or GARP-2 load, for details please see Reference [39]: PBPGW0040LOAD Number of scans where the PGW CPU load on PGWB was between 0% and 40% PBPGW4160LOAD Number of scans where the PGW CPU load on PGWB was between 41% and 60%. PBPGW6180LOAD Number of scans where the PGW CPU load on PGWB was between 61% and 80%. PBPGW8190LOAD Number of scans where the PGW CPU load on PGWB was between 81% and 90%. PBPGW9100LOAD Number of scans where the PGW CPU load on PGWB was between 91% and 100%. G2PGW0040LOAD Number of scans where the GARP-2 CPU Load was between 0% and 40%. G2PGW4160LOAD Number of scans where the GARP-2 CPU Load was between 41% and 60%. G2PGW6180LOAD Number of scans where the GARP-2 CPU Load was between 61% and 80%. G2PGW8190LOAD Number of scans where the GARP-2 CPU Load was between 81% and 90%. G2PGW9100LOAD Number of scans where the GARP-2 CPU Load was between 91% and 100%. 7.3.8 PGW Load Distribution The statistics of SCGR relocations described below, are supported by STS counters, and thus possible to use in OSS. 202 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters The operator is able to monitor the success/attempt ratio for all SCGR relocations, i.e., some measurement of quality can be shown for this feature. The first four counters in the list below, are continuously updated with the attempted and successful number of SCGR relocations, and, also sorted on the causes of load being above the “high” or “very high” thresholds. The last counter is continuously updated with the number of PGW-RPs where high CPU-load have been detected, please see Reference [39] for details. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 203 User Description, Radio Network Statistics Object type: PGWLDIST Title: Counters for PGW load distribution The following STS counters are used for PGW load distribution: 7.3.9 VHLSCGREL Number of attempted SCGR relocations caused by “very high” load. SVHLSCGREL Number of successful SCGR relocations caused by “very high” load. HLSCGREL Number of attempted SCGR relocations caused by “high” load. SHLSCGREL Number of successful SCGR relocations caused by “high” load. PGWHLRPP Number of PGW-RPs where the CPU load has exceeded the "high" load Threshold. PGW-STN Link Utilization In order to check the PGW-STN link load, the counters (shown in the list below) in object type ABISIP shall be used to plot a histogram for the load situation uplink or downlink, respectively. The utilization is measured per STN and measurements are relative the total engineered bandwidth set by parameters MBWDL and MBWUL, respectively. The traffic load on the PGW - STN link is calculated as the quotient between the accumulated throughput for the TGs connected to the same STN and the accumulated engineered bandwidth set for those TGs. The load is calculated once per second, as a percentage value. The counter for the appropriate interval is then incremented by one. As these counters are calculated per STN, but presented per TG, the counter values will be the same for all TGs connected to the same STN. Note: The engineered bandwidth normally is set with over-provisioning in a multiple TG case. This will have the effect that the PGW-STN link load counters indicate a lower load on the link compared to the real load situation. Hence, the level of over-provisioning must be taken into consideration when interpreting the link load counters. Object type: ABISIP Title: Counters for STN load distribution The following STS counters are used for STN load distribution histograms: 204 DL7075STNLOAD Number of scans where the traffic load on the PGW STN link was between 70% and 75%, DL. DL7680STNLOAD Number of scans where the traffic load on the PGW STN link was between 76% and 80%, DL. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters 7.3.10 DL8185STNLOAD Number of scans where the traffic load on the PGW STN link was between 81% and 85%, DL. DL8690STNLOAD Number of scans where the traffic load on the PGW STN link was between 86% and 90%, DL. DL9195STNLOAD Number of scans where the traffic load on the PGW STN link was between 91% and 95%, DL. DL9600STNLOAD Number of scans where the traffic load on the PGW STN link was between 96% and 100%, DL. DL100STNLOAD Number of scans where the traffic load on the PGW STN link was above 100%, DL. UL7075STNLOAD Number of scans where the traffic load on the PGW STN link was between 70% and 75%, UL. UL7680STNLOAD Number of scans where the traffic load on the PGW STN link was between 76% and 80%, UL. UL8185STNLOAD Number of scans where the traffic load on the PGW STN link was between 81% and 85%, UL. UL8690STNLOAD Number of scans where the traffic load on the PGW STN link was between 86% and 90%, UL. UL9195STNLOAD Number of scans where the traffic load on the PGW STN link was between 91% and 95%, UL. UL9600STNLOAD Number of scans where the traffic load on the PGW STN link was between 96% and 100%, UL. UL100STNLOAD Number of scans where the traffic load on the PGW STN link was above 100%, UL Super Channel load In order to check the super channel load distribution, the super channel counters in object type SUPERCH2 shall be used in order to plot a histogram for the load situation uplink or downlink, respectively. Please see Section 7.5.2 on page 210 for details. Note that the counters in SUPERCH2 do not yield any values when ABIS over IP is used. 7.4 STN counters used in Formulae There are a number of counters available from the STN node, but only a few which is used in formulas in Section 7.1 Frame Loss Ratio Formulas for Packet Abis on page 191 - Section 7.2 Delay measurements Formulas for Packet Abis 216/1553-HSC 103 12/16 Uen E | 2010-11-10 205 User Description, Radio Network Statistics on page 193 are presented in this section. In order to have information about all available STN counters, please see Reference [41]. PingDelayAverage Average delay of packets received measured in tenths of milliseconds. Unit: 1/10 ms 7.5 Summary of STS Counters for Abis over IP and Abis Optimization 7.5.1 Object Type SUPERCH Object type: SUPERCH The counters in this object type are used to monitor Abis Utilization for Abis Optimization (for more information please see Reference [38]) and frames lost for both Abis Optimization and Abis over IP. Note that some counters do not yield any values when ABIS over IP is used (as indicated below on a per counter basis). The operator can monitor the utilization of the Abis links to each base station in order to determine when new Abis resources needs to be added or when resources can be removed. KBSENT Accumulated number of kbytes sent by the PGW. Unit: KB KBREC Accumulated number of kbytes received by the PGW. Unit: KB KBSCAN The time for which the counters KBSENT and KBREC have been accumulated. Unit: sec To be able to detect any traffic peaks, the following counters is used with Abis Optimization: KBMAXSENT Maximum number of kbytes per second sent by the PGW during the last 15-minute interval. Note: This counter is only valid for Abis Optimization and will show value 0 for a super channel group where Abis over IP is used for transmission. Unit: KB 206 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters KBMAXREC Maximum number of kbytes per second received by the PGW during the last 15-minute interval. Note: This counter is only valid for Abis Optimization and will show value 0 for a super channel group where Abis over IP is used for transmission. Unit: KB THRULPACK This counter shows the number of CS traffic frames and PS traffic frames discarded on the UL by the BTS due to Abis overload. The same information can also be obtained by ULPSSCBUFTHR+ULSCBUFTHR. Note: THRDLPACK This counter shows the total number of CS traffic frames and PS traffic frames discarded on the DL by the PGW due to Abis overload. Please note that the sum DLPSSCBUFTHR+DLCSSCBUFTHR is equal to the value shown by THRDLPACK. Note: LOSTULPACK This counter is only valid for Abis Optimization and will show value 0 for a super channel group where Abis over IP is used for transmission. However, please note that ULPSSCBUFTHR+ULSCBUFTHR is working both for Abis over IP and Abis Optimization. These counters are only valid for Abis Optimization and will show value 0 for a super channel group where Abis over IP is used for transmission. Number of lost CS and PS traffic frames on the UL during last recording period. This includes all frames that are missing in PGW, that is frames that were corrupted in transmission network as well as frames that were not sent by the BTS due to super channel overload. Please, note that LOSTULPACK=FCSLOSTUL+FPSL OSTUL. FPSLOSTUL This counter counts the total number of lost PS traffic frames on the uplink. The number of lost PS traffic frames on the uplink includes all frames that are missing in the PGW, that is frames that were corrupted in transmission network as well as frames that were not sent by the BTS due to super channel overload. This is calculated in the PGW. FCSLOSTUL This counter counts the total number of lost CS traffic frames on the uplink. The number of lost CS traffic 216/1553-HSC 103 12/16 Uen E | 2010-11-10 207 User Description, Radio Network Statistics frames on the uplink includes all frames that are missing in the PGW, that is frames that were corrupted in transmission network as well as frames that were not sent by the BTS due to super channel overload. This is calculated in the PGW. LOSTDLPACK Number of lost CS and PS traffic frames on the DL during last recording period. This includes all frames that are missing in BTS, that is frames that were corrupted in transmission network as well as frames that were not sent by the PGW due to super channel overload. Please, note that LOSTDLPACK=FCSLOSTDL+FPSL OSTDL. Note: FPSLOSTDL This counter counts the total number of lost PS traffic frames on the downlink. The number of lost PS traffic frames on the downlink includes all frames that are missing in the BTS, that is frames that were corrupted in transmission network as well as frames that were not sent by the PGW due to super channel overload. This is calculated in the BTS. FCSLOSTDL This counter counts the total number of lost CS traffic frames on the downlink. The number of lost CS traffic frames on the downlink includes all frames that are missing in the BTS, that is frames that were corrupted in transmission network as well as frames that were not sent by the PGW due to super channel overload. This is calculated in the BTS. Note: AVDELDLSCBUF This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. This counter indicates the average delay of CS and PS traffic frames in the super channel buffers downlink, in the PGW. Note: 208 This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. The counter contains the average value for the last 15 minutes. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters Note: This counter is only valid for Abis Optimization and will show value 0 for a super channel group where Abis over IP is used for transmission. Unit: ms AVDELULSCBUF This counter indicates the average delay of CS and PS traffic frames in the super channel buffers uplink, in the BTS. Note: The downlink jitter buffer delay is measured in the BTS and reported every 5 minutes to the BSC. The counter value is a moving average over the last 15 minutes, calculated from three consecutive values from the BTS. Unit: ms TOTFRDLSCBUF This counter counts the total number of CS traffic frames entering the super channel buffers downlink, in the PGW. Note that this counter does include discarded frames in the super channel buffer. TOTFRULSCBUF This counter counts the total number of CS traffic frames entering the super channel buffers uplink, in the BTS. Note that this means that this counter does include frames discarded in the super channel buffer. TOTDLPSSCFRBUF This counter counts the total number of PS traffic frames entering the super channel buffers downlink, in the PGW. Note that this counter does include discarded frames in the super channel buffer. TOTULPSSCFRBUF This counter counts the total number of PS traffic frames entering the super channel buffers uplink, in the BTS. Note that this means that this counter does include frames discarded in the super channel buffer. DLCSSCBUFTHR This counter counts the number of CS traffic frames discarded in the super channel buffers downlink, in the PGW Note: ULSCBUFTHR 216/1553-HSC 103 12/16 Uen E | 2010-11-10 This counter is only valid for Abis Optimization and will show value 0 for a super channel group where Abis over IP is used for transmission. This counter counts the number of CS traffic frames discarded in the super channel buffers uplink, in the BTS. 209 User Description, Radio Network Statistics DLPSSCBUFTHR This counter counts the number of PS traffic frames discarded in the super channel buffers downlink, in the PGW. Note: ULPSSCBUFTHR 7.5.2 This counter is only valid for Abis Optimization and will show value 0 for a super channel group where Abis over IP is used for transmission. This counter counts the number of PS traffic frames discarded in the super channel buffers uplink, in the BTS. Object Type SUPERCH2 In order to check the super channel load distribution, the load counters in object type SUPERCH2 shall be used in order to plot a histogram for the load situation uplink or downlink, respectively.In this Object type there are also counters to monitor if and for how long time Abis load handling have reduced PS or CS traffic. Note that the counters in SUPERCH2 do not yield any values when ABIS over IP is used. Object type: SUPERCH2 Title: Counters for super channel load distribution and load handling. The following STS counters are used for super channel load distribution histograms: 210 DL7075SCLOAD Number of scans where the traffic load was between 70% and 75%, DL. Calculated in PGW. DL7680SCLOAD Number of scans where the traffic load was between 76% and 80%, DL. Calculated in PGW. DL8185SCLOAD Number of scans where the traffic load was between 81% and 85%, DL. Calculated in PGW. DL8690SCLOAD Number of scans where the traffic load was between 86% and 90%, DL. Calculated in PGW. DL9195SCLOAD Number of scans where the traffic load was between 91% and 95%, DL. Calculated in PGW. DL9600SCLOAD Number of scans where the traffic load was between 96% and 100%, DL. Calculated in PGW. UL7075SCLOAD Number of scans where the traffic load was between 70% and 75%, UL. Calculated in PGW. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters 7.5.3 UL7680SCLOAD Number of scans where the traffic load was between 76% and 80%, UL. Calculated in PGW. UL8185SCLOAD Number of scans where the traffic load was between 81% and 85%, UL. Calculated in PGW. UL8690SCLOAD Number of scans where the traffic load was between 86% and 90%, UL. Calculated in PGW. UL9195SCLOAD Number of scans where the traffic load was between 91% and 95%, UL. Calculated in PGW. UL9600SCLOAD Number of scans where the traffic load was between 96% and 100%, UL. Calculated in PGW. SCOVLPSREG Indicates how long time (in seconds) the PS traffic reduction has been active for Abis Optimization. Stepping of this counter indicates that a number of PS data scheduling has been omitted. SCOVLCSREG Indicates how long time (in seconds) the CS traffic reduction has been active for Abis Optimization. Stepping of this counter indicates that almost all PS data scheduling has been omitted. Stepping of this counter also indicates a decreased level of new and existing CS calls. Object Type ABISIP The counters described in object type ABISIP are used to monitor Abis over IP and counters are per TG. For more information see Reference [37] Object type: ABISIP IPSENTKBYTES Accumulated number of kilo bytes of DL data sent by the BSC, reported per TG. The measurement includes all Speech, CS data, GPRS, RSL signaling and OML signaling frames. The measurement includes the length of the entire IP packets including IP header. Note: This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Unit: kbytes IPRECKBYTES 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Accumulated number of kilo bytes of UL data received by the BSC, reported per TG. The measurement includes all Speech, CS data, GPRS, RSL signaling and 211 User Description, Radio Network Statistics OML signaling frames. The measurement includes the length of the entire IP packets including IP header. Note: This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Unit: kbytes IPNUMSCAN The time for which the counters IPSENTKBYTES and IPRECKBYTES have been accumulated Unit: sec IPULRECPACK Accumulated number of IP packets received UL on the PGW - STN link, reported per TG. Note: IPDLSENTPACK Accumulated number of IP packets sent DL on the PGW - STN link, reported per TG. Note: IPLOSTPACKUL 212 This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Accumulated number of IP packets either lost on the UL or received with a checksum error, reported per TG. Note: DL7075STNLOAD This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 70% and 75%, DL 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters Note: DL7680STNLOAD Number of scans where the traffic load on the PGW STN link was between 76% and 80%, DL Note: DL8185STNLOAD 216/1553-HSC 103 12/16 Uen E | 2010-11-10 This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 91% and 95%, DL Note: DL9600STNLOAD This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 86% and 90%, DL Note: DL9195STNLOAD This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 81% and 85%, DL Note: DL8690STNLOAD This counter will show different values depending on if Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 96% and 100%, DL 213 User Description, Radio Network Statistics Note: DL100STNLOAD Number of scans where the traffic load on the PGW STN link was above 100%, DL Note: UL7075STNLOAD 214 This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 81% and 85%, UL Note: UL8690STNLOAD This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 76% and 80%, UL Note: UL8185STNLOAD This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 70% and 75%, UL Note: UL7680STNLOAD This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 86% and 90%, UL 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters Note: UL9195STNLOAD Number of scans where the traffic load on the PGW STN link was between 91% and 95%, UL Note: UL9600STNLOAD This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. This counter counts the number of seconds that actions to reduce severe overload have been initiated. Load reduction is in this case performed by completely removing PS traffic frames from the Abis interface, UL and DL. This is triggered by a high number (level 1 threshold) of RSL signalling (SAPI 0) retransmissions or OML signalling (SAPI 62) retransmissions on LAPD in the downlink, or when the CS-regulation functions have be active for a long time (45 seconds). For CS-regulation see Section 7.3.3 on page 198. Note: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was above 100%, UL Note: IPOVLL1 This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. Number of scans where the traffic load on the PGW STN link was between 96% and 100%, UL Note: UL100STNLOAD This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. IPOVLL1 can be stepped even if the 'IP Overload Robustness' feature isn't active and the CS-regulation functions have been active for more than 45 seconds. 215 User Description, Radio Network Statistics IPOVLL2 This counter counts the number of seconds that actions to reduce severe overload have been initiated. Load reduction is in this case performed by completely removing both PS and CS traffic frames from the Abis interface, UL and DL. This is triggered by a high number (level 2 threshold) of RSL signalling (SAPI 0) retransmissions or OML signalling (SAPI 62) retransmissions on LAPD in the downlink. PSDISCOVL Indicates the number of discarded PS traffic frames DL at overload actions. CSDISCOVL Indicates the number of discarded CS traffic frames DL at overload actions. Note: 7.5.4 This counter will show different values depending on if the Abis Local Connectivity (ALC) introduced in BSS 08A is used or not. Please, see the User Description, Abis Local Connectivity, Reference [43], regarding details about the ALC impact on this counter. IPOVLPSREG Indicates how long time the PS traffic reduction has been active for Abis over IP. Measured in seconds. Stepping of this counter indicates that a number of PS data scheduling has been omitted. IPOVLCSREG Indicates how long time the CS traffic reduction has been active for Abis over IP. Measured in seconds. Stepping of this counter indicates that almost all PS data scheduling has been omitted. Stepping of this counter also indicates a decreased level of new and existing CS calls. Object Type ABISTG The counters described in this chapter are used to monitor buffer delays and drops in packet Abis (Optimization and IP) and counters are per TG. For more information see Reference [37] and Reference [38] Object type: ABISTG DL0025JITBUFDEL Number of CS traffic frames where the jitter buffer delay DL was between 0% and 25% of the jitter buffer size setting. Calculated in BTS. DL2650JITBUFDEL Number of CS traffic frames where the jitter buffer delay DL was between 26% and 50% of the jitter buffer size setting. Calculated in BTS. 216 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters DL5175JITBUFDEL Number of CS traffic frames where the jitter buffer delay DL was between 51% and 75% of the jitter buffer size setting. Calculated in BTS. DL7600JITBUFDEL Number of CS traffic frames where the jitter buffer delay DL was between 76% and 100% of the jitter buffer size setting. Calculated in BTS DL100JITBUFDEL Number of CS traffic frames where the jitter buffer delay DL was more than 100% of the jitter buffer size setting. Calculated in BTS. DLJITBUFAVDEL Average jitter buffer delay DL [ms]. Calculated in BTS Unit: ms Note: The downlink jitter buffer delay is measured in the BTS and reported every 5 minutes to the BSC. The counter value is a moving average over the last 15 minutes, calculated from three consecutive values from the BTS. Note: To have a measure that works for any selected reporting period, please use the following measure of jitter buffer delay: FJBUFDELDL/FJBUFDLSCAN. Note that these two counters report on Super Channel level and are found in object type SCABISDEL. UL0025JITBUFDEL Number of CS traffic frames where the jitter buffer delay UL was between 0% and 25% of the jitter buffer size setting. Calculated in PGW. UL2650JITBUFDEL Number of CS traffic frames where the jitter buffer delay UL was between 26% and 50% of the jitter buffer size setting. Calculated in PGW. UL5175JITBUFDEL Number of CS traffic frames where the jitter buffer delay UL was between 51% and 75% of the jitter buffer size setting. Calculated in PGW. UL7600JITBUFDEL Number of CS traffic frames where the jitter buffer delay UL was between 76% and 100% of the jitter buffer size setting. Calculated in PGW. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 217 User Description, Radio Network Statistics UL100JITBUFDEL Number of CS traffic frames where the jitter buffer delay UL was more than 100% of the jitter buffer size setting. Calculated in PGW. ULJITBUFAVDEL Average jitter buffer delay UL [ms]. Calculated in PGW Unit: ms Note: The counter contains the average value for the last 15 minutes. Note: To have a measure that works for any selected reporting period, please use the following measure of jitter buffer delay: FJBUFDELUL/FJBUFULSCAN. Note that these two counters report on Super Channel level and are found in object type SCABISDEL. DLDROPJBUF Number of discarded CS traffic frames in jitter buffer, DL. Calculated in BTS ULDROPJBUF Number of discarded CS traffic frames in jitter buffer, UL. Calculated in PGW. Note: BUNDG0AVEDL This counter will show value 0 for Abis Optimization as no packets in the jitterbuffer will be dropped. Average bundling delay in the bundling group containing SAPI=0 (RSL). Unit: 0.1 ms BUNDG1AVEDL Note: The counter contains the average value for the last 15 minutes. Note: This counter will show value 0 for Abis Optimization as the bundling groups is only used for Abis over IP. Average bundling delay in the bundling group containing SAPI=10 (Speech). Unit: 0.1 ms 218 Note: The counter contains the average value for the last 15 minutes. Note: Tthis counter will show value 0 for Abis Optimization as the bundling groups is only used for Abis over IP. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Abis over IP and Abis Optimization Measurements and Counters BUNDG2AVEDL Average bundling delay in the bundling group containing SAPI=11 (CS Data). Unit: 0.1 ms BUNDG3AVEDL Note: The counter contains the average value for the last 15 minutes. Note: This counter will show value 0 for Abis Optimization as the bundling groups is only used for Abis over IP. Average bundling delay in the bundling group containing SAPI=12 (GPRS/EDGE data). Unit: 0.1 ms BUNDG4AVEDL Note: The counter contains the average value for the last 15 minutes. Note: This counter will show value 0 for Abis Optimization as the bundling groups is only used for Abis over IP. Average bundling delay in the bundling group containing SAPI=62. Unit: 0.1 ms 7.5.5 Note: The counter contains the average value for the last 15 minutes. Note: This counter will show value 0 for Abis Optimization as the bundling groups is only used for Abis over IP. Object Type SCABISDEL The counters in object type SCABISDEL are used for measurements on jitter buffer delay and super channel buffer delay per super channel . The measurements are valid for Abis over IP and Abis Optimization. Note: In the jitter buffer only CS frames are handled, while in the Super Channel buffer both CS and PS frames are handled. Object type: SCABISDEL FJBUFDELDL Accumulated jitter buffer delay in milliseconds in the downlink direction. Calculated in BTS. Unit: milliseconds FJBUFDLSCAN 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Number of accumulations for counter FJBUFDELDL. 219 User Description, Radio Network Statistics FJBUFDELUL Accumulated jitter buffer delay in milliseconds in the uplink direction. Calculated in PGW. Unit: milliseconds FJBUFULSCAN Number of accumulations for counter FJBUFDELUL. FSCBUFDELDL Accumulated super channel buffer delay in milliseconds in the downlink direction. Calculated in PGW. Unit: milliseconds Note: FSCBUFDLSCAN Number of accumulations for counter FSCBUFDELDL. Note: FSCBUFDELUL Note that this counter only is valid when Abis Optimization is used. For Abis over IP the super channel buffer is located in STN. Note that this counter only is valid when Abis Optimization is used. For Abis over IP the super channel buffer is located in STN. Accumulated super channel buffer delay in milliseconds in the uplink direction. Calculated in BTS. Unit: milliseconds FSCBUFULSCAN 220 Number of accumulations for counter FSCBUFDELUL. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Packet Abis Influence on Important BSS KPI and PI Measurements 8 Packet Abis Influence on Important BSS KPI and PI Measurements In the following sections, the influence on important BSS KPI (Reference [42]) and PIs due to packet Abis is described. The descriptions is only valid when packet Abis is not down, as a complete interruption in the transmission (e.g. problems with a leased IP-link) will result in strange effects on the BSS KPIs. 8.1 IP Transfer interrupts These KPIs will be influenced by packet Abis, but this is not directly measurable using packet Abis counters as packet Abis is not aware of connections (it just shuffles single packets). If the interrupts persist for longer times, there will be TBFs lost and this will be visible in counters LDISRR, LDISRRSUB, IAULREL, IAULRELSUB. In order to judge if IP Interrupts are due to Abis over IP overload please use counters IPOVLL1 (Level 1 actions) and IPOVLL2 (Level 1 actions) and formulas for frames lost due to overload ratio (Section 7.3.4 Overload handling Abis over IP on page 199), respectively. Overload handling is active as long as the overload situation remains (Level 1: typically 30 sec for PS data, Level 2: typically 2 - 4 sec for CS data) and is then terminated. In order to judge if IP interrupts are due to Abis Optimization, please use formulas for discarded frames due to overload (Section 7.3.5 Overload handling Abis Optimization on page 200). Note: 8.2 Short interrupts on packet Abis will not necessarily cause an interrupt on the BSS level. Retransmission procedures will save the BSS transfer (TBF) if the Abis disturbance is short enough (a few seconds). GPRS Availability This KPI is influenced by Abis outage, and indirectly Abis outage can be indicated by looking at Abis overload counters IPOVLL1 and IPOVLL2, respectively. 8.3 IP Latency GPRS Under normal packet Abis conditions the BSS latency KPIs are valid and includes packet Abis delays. However, if packets are arriving to early or to late as compared to the measuring window used for BSS latency measurements the BSS latency measurements will not include the packet Abis delay samples. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 221 User Description, Radio Network Statistics 8.4 IP Throughput and Radio Link Bitrate measurements Today three LQC algorithms exist in the BSS system: LA, LA/IR and LA/IR-BLER. When using LA/IR or LA the LQC algorithm uses MeanBEP for measuring radio link quality, frames lost on the packet Abis link will yield retransmissions which will lower the observed BSS Throughput and Radio Link Bit-rate. However, in this case the system will not misinterpret this as due to bad radio conditions and the coding scheme will not be changed. Using LA/IR-BLER the LQC algorithm uses BLER as the measure of air interface quality. If frames are lost on the packet Abis link this will yield a lower observed BSS Throughput and Radio Link Bit-rate as discussed above. In addition to this the system will misinterpret the situation as due to bad radio conditions and change to a lower coding scheme. This results in a lower bit rate on both packet Abis and the air interface which will yield an additional lowering of the observed BSS Radio Link Bit-rate and Throughput. Hence, in both cases discussed above, large frame losses (not single frames) on packet Abis will result in a lower BSS Radio Link Bit rate and Throughput observed. However, it is not possible to directly judge from these KPIs and PIs if the effect is due to packet Abis or air interface problems. Note: In the case where LA/IR or LA is used, the effect is probably smaller as the LQC will not lower the coding scheme due to packets lost on the packet Abis interface. BSS Throughput and Radio Link Bit Rate measurements are affected by large packet losses and delays on the packet Abis links. In order to judge if packet Abis influence BSS Throughput measurements one can look at packet Abis lost frame ratio measurements (Section 7.1 Frame Loss Ratio Formulas for Packet Abis on page 191), packet Abis delay measurements (Section 7.2 Delay measurements Formulas for Packet Abis on page 193), and packet Abis overload measurements (Section 7.3.4 Overload handling Abis over IP on page 199 - Section 7.3.5 Overload handling Abis Optimization on page 200). If there is an Abis overload situation, this may result in fewer available PDCHs. This will be visible in multislot utilization and traffic load counters found in object types TRAFDLGPRS, TRAFULGPRS, TRAFGPRS2 and TRAFGPRS3, respectively. Note: 222 The GPRS throughput KPIs will be affected due to the overload actions that is taken when counters IPOVLL1, IPOVLL2, IPOVLPSREG, IPOVLCSREG, SCOVLPSREG and SCOVLCSREG are stepped. When these counters are stepped an impact on the number of TBFs will occur. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Packet Abis Influence on Important BSS KPI and PI Measurements 8.5 IP User Data Volume (measured per hour) These KPIs are influenced by packet Abis but it is not possible to measure PS payload volume on Packet Abis. If Packet ABIS is under-dimensioned, this may affect the end user services negatively, which may result in lower traffic volume due to changed end users behavior. In order to have an idea about the Packet Abis situation one can use formulas for total packet ABIS loss ratio (Section 7.1 Frame Loss Ratio Formulas for Packet Abis on page 191) and overload counters (Section 7.3.4 Overload handling Abis over IP on page 199 - Section 7.3.5 Overload handling Abis Optimization on page 200). 8.6 CS Accessibility - Random access success rate This KPI will not be influenced by packet Abis as overload mechanism on packet Abis try to keep CHANNEL REQUIRED message. 8.7 CS Accessibility - SDCCH Time Congestion Under normal operation this KPI will not be affected by packet Abis as, attempts to allocate SDCCH resources will not be rejected even at high packet Abis load. However, at packet Abis at link outage the KPI will be affected, but this cannot be directly measured using packet Abis counters. 8.8 CS Accessibility - SDCCH Drop rate This KPI will not be influenced by packet Abis. 8.9 CS Accessibility - TCH Assignment success rate Packet Abis overload handling or outage will affect this KPI. In order to judge packet Abis influence on the KPI, please use formulas for packet Abis overload (Section 7.3.4 Overload handling Abis over IP on page 199 - Section 7.3.5 Overload handling Abis Optimization on page 200). The percentage of rejected CS connection attempts due to Abis overload can be measured by Page 200. If the Abis link is continuously overloaded new call set up on TCH will be rejected the counter OVERLOADREJCON will step. Note: 8.10 The counter OVERLOADREJCON works for both Abis Optimization and Abis over IP and will step if a TCH allocation (for CS) is rejected due to ABIS overload. CS Retainability - TCH Drop rate This KPI will not be influenced by packet Abis. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 223 User Description, Radio Network Statistics 8.11 CS Retainability – Handover Success Rate and Lost Rate These KPIs will not be influenced by packet Abis. This is because the handover counters start counting after which a Handover Command message has been issued, and at that stage Abis resources are already secured. 8.12 CS Integrity SQI These KPIs are designed to measure speech quality related to the radio link quality and will not be influenced by packet Abis. In order to have an idea about possible packet Abis impact on speech quality, one can look at the total packet loss ratio (Section 7.1 Frame Loss Ratio Formulas for Packet Abis on page 191) and total delay (Section 7.2 Delay measurements Formulas for Packet Abis on page 193) for packet Abis. As a rule-of-thumb the acceptable frame discard rate depends on the codec in use but is typically in the 0.5-1% range end-to-end. In order to achieve this, the discard rate on Abis should be below 0.1 % since most of the losses are expected in the air interface [4]. 8.13 CS Traffic Volume If Packet ABIS is properly dimensioned this KPI will not be infuenced by packet Abis. However, at packet Abis congestion may result in a lower observed traffic volume. In order to indirectly measure if a lower CS traffic volume is due to problems on packet Abis, one can use the formulas for packet Abis overload handling discussed in Section 7.3.4 Overload handling Abis over IP on page 199 and Section 7.3.5 Overload handling Abis Optimization on page 200). 224 216/1553-HSC 103 12/16 Uen E | 2010-11-10 A over IP Measurements and Counters 9 A over IP Measurements and Counters The BSS feature A-Interface over IP uses IP networks, instead of Time-Division Multiplexing (TDM) networks, for transport of A-interface user plane data (speech and circuit switched data) between BSS and the Core Network (CN). A-interface over IP is the enabler for achieving transmission bandwidth savings and improved speech quality in MS-MS calls. As transcoders can be placed in CN, compressed speech can be transmitted over the A-interface instead of sending speech with 64-kbps Pulse-Code Modulation (PCM) over a TDM link. The feature also enables Transcoder Free Operation (TrFO) when codec types used in both ends of a call are compatible and no transcoders are involved in the call. In order to supervise the A over IP feature (see Reference [44]) the counters discussed in this chapter can be used. There are a number of STS counters defined for A-interface over IP: • AGW CPU load counters are found in object type AGW • Traffic level counters are found in object type AGWTRAF • Counter for RTP configuration changes are found in object type AOIP. • Counters for monitoring the capacity lock for the A over IP interface are found in object type AOIPCAP. 9.1 Counters for AGW RP CPU Load 9.1.1 Object Types and Counters Object type: AGW Title: Counters for AGW RP CPU Load. G2AGW0040LOAD Total number of scans where the GARP-2 load was between 0% and 40%. G2AGW4160LOAD Total number of scans where the GARP-2 load was between 41% and 60%. G2AGW6180LOAD Total number of scans where the GARP-2 load was between 61% and 80%. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 225 User Description, Radio Network Statistics G2AGW8190LOAD Total number of scans where the GARP-2 load was between 81% and 90%. G2AGW9100LOAD Total number of scans where the GARP-2 load was between 91% and 100%. 9.1.2 Description The counters in object type AGW are defined per TRC. The counters show a distribution of processor load, comprising all the regional processors of type GARP-2 in the AGW. The operating system in the regional processor traces the processor load continuously. The load in percent is collected every 500 ms. Depending on the current load, the appropriate counter is incremented. Note that measurements for regional processors on standby are included in the counter values. 9.2 Counters for AGW RP Traffic 9.2.1 Object Types and Counters Object type: AGWTRAF Title: Counters for AGW RP Traffic. 226 FDELAY The accumulated downlink frame delay in ms through the jitter buffers in the AGW. FDELAYSCAN The number of accumulations for the counter FDELAY. REPLF The counter REPLF counts the total number of RTP packets that are considered lost in transmission network (lost or delayed packets so that the jitter buffer in AGW is empty). The counter includes RTP packets with compressed format and RTP packets with PCM format. TRALACC The accumulated number of ongoing connections in the AGW TRALSCAN The number of accumulations for the counter TRALACC SENTSPF The number of RTP packets with compressed speech format sent over non-multiplexed connections. RECSPF The number of RTP packets with compressed speech format received over non-multiplexed connections. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 A over IP Measurements and Counters KBSENT The amount of data (in kB) sent by the AGW with the compressed speech format over non-multiplexed connections. The amount includes payload, RTP header and UDP header. KBREC The amount of data (in kB) received by the AGW with the compressed speech format over non-multiplexed connections. The amount includes payload, RTP header and UDP header. SENTSPFPCM The number of RTP packets with speech frames using PCM format sent over non-multiplexed connections. RECSPFPCM The number of RTP packets with speech frames using PCM format received over non-multiplexed connections. SENTDFPCM The number of RTP packets with CS data in PCM format sent over non-multiplexed connections. RECDFPCM The number of RTP packets with CS data in PCM format received over non-multiplexed connections. KBSENTPCM The amount of data (in kB) sent by the AGW, jn PCM format over non-multiplexed connections. The amount includes payload, RTP header and UDP header. KBRECPCM The amount of data (in kB) received by the AGW, in PCM format over non-multiplexed connections. The amount includes payload, RTP header and UDP header. SENTMUXPKTMBS The number of UDP/IP multiplexed packets sent due to maximum bundling size reached. SENTMUXPKTMBT The number of UDP/IP multiplexed packets sent due to maximum bundling time reached. KBRECMUX The received number of kilobytes over multiplexed connections (UDP header + RTP headers + payload + multiplexed headers). KBSENTMUX The sent number of kilobytes over multiplexed connections (UDP headers + RTP headers + payload + multiplexed headers). SENTSPFMUX The number of RTP packets with compressed speech format sent over multiplexed connections. RECSPFMUX The number of RTP packets with compressed speech format received over multiplexed connections. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 227 User Description, Radio Network Statistics SENTSPFPCMMUX The number of RTP packets with speech in PCM format sent over multiplexed connections. RECSPFPCMMUX The number of RTP packets with speech in PCM format received over multiplexed connections. 9.2.2 SENTDFPCMMUX The number of RTP packets with CS data in PCM format sent over multiplexed connections. RECDFPCMMUX The number of RTP packets with CS data in PCM format received over multiplexed connections. Description The counters in object type AGWTRAF are defined per TRC. Traffic level The counters in object type AGWTRAF can be used to determine Traffic level in the AGW, Frame Delay through the jitter buffers in the AGW and number of jitter buffer under-runs. Throughput both when using compressed format and PCM format for both non-multiplexed and multiplexed connections can be determined. 9.3 RTP Configuration Changes Counters for A over IP 9.3.1 Object Types and Counters Object type: AOIP Title: Counters for A over IP 228 CODECCHATT The number of attempts to change codec type. Valid for CS speech calls. CODECCHSUCC The number of successful changes of codec type. Valid for CS speech calls. TRMCHATT The number of attempts to change transmission type (TDM or IP). Valid for CS speech calls and CS data calls. TRMCHSUCC The number of successful changes of transmission type (TDM or IP). Valid for CS speech calls and CS data calls. CODECSETCATT Counter is reserved for future use. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 A over IP Measurements and Counters CODECSETCSUCC Counter is reserved for future use. 9.3.2 Description The counters in object type AOIP are defined per TRC. The counters step in case of Intra BSC Handovers where a change of configuration is needed, for example changing codec type, codec set for AMR or transmission type. In these cases the MSC is supporting the handover. 9.4 Capacity Locks for the A over IP Interface 9.4.1 Object Types and Counters Object type: AOIPCAP Title: Counters for monitoring the capacity lock for the A over IP interface 9.4.2 AOIPATT Number of attempts to seize or preseize AGW resources. AOIPCONGCL Number of attempts to seize or preseize AGW resources rejected due to capacity lock. AOIPCONGOTH Number of attempts to seize or preseize AGW resources rejected due to lack of AGW resources. AOIPPEAK Peak number of AoIP calls during last hour. AOIPTCONG Total time in seconds when no A over IP resources have been available for new traffic due to capacity lock mechanism. Description The counters in object type AOIPCAP are defined per TRC. The counters are used to monitor peak utilization, congestion and capacity lock for the A over IP interface. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 229 User Description, Radio Network Statistics 230 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters 10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters Please, note that the discussion in the following chapters is done under the assumption that the Abis link is not congested. When dimensioning the GPRS/EGPRS radio network the objective is to place load on each channel (kbps/pdch) so that the GPRS/EGPRS users will experience an estimated throughput (kbps) on application level. The throughput achieved in a GPRS/EGPRS radio network is primarily depended on the channel capabilities and the amount of GPRS/EGPRS traffic. Furthermore it is dependent on the interference environment, MS multislot class and the type of traffic generated by the users. This User Description presents Ericsson's method to dimension the GPRS/EGPRS radio network for a certain median end-user throughput for TCP/IP traffic with the help of STS counters. The method is suitable for: • dimensioning the GPRS/EGPRS radio network for a certain median end-user throughput. • retaining the current GPRS/EGPRS end-user throughput at increased PS traffic. The dimensioning is based on the peak hour when the PDCH utilization is at peak. This could either be at CS peak hour (few PDCHs available) or at PS peak hour (high load on available PDCHs). This dimensioning methodology does not consider impact from streaming. A way to consider streaming is to reduce a certain amount of bandwidth that is not available for interactive and background traffic, e.g. if streaming is estimated to take 10 kbps per PDCH dimensioning should be done for 10 kbps more than the required end user throughput. Note also that the simulations are not valid for UDP (e.g. streaming) since it has other characteristics than TCP. The dimensioning method described in document only considers the air interface. Proper dimensioning of the BSC requires support for more PDCHs in the PCU in order not to jeopardize GPRS performance. For PCU and Gb interface dimensioning, see Reference [2]. In this dimensioning method semi-dedicated PDCHs should be treated in the same way as dedicated PDCHs, i.e. whenever dedicated PDCHs are mentioned in the formulas also semi-dedicated PDCHs are applicable. In the formulas when FPDCH is mentioned also SPDCH shall be included. When dimensioning resources for DTM consideration need to be taken that fewer timeslots will be available for PS, since one timeslot is used for CS. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 231 User Description, Radio Network Statistics Note:This method is based on STS statistics, therefore the result can be misleading if only low volumes of packet switched traffic exist in the GPRS network. 10.1 How to Use This Dimensioning Methodology There are four important concepts in dimensioning GPRS/EGPRS that the reader should be familiar with. These are: • PDCH Utilization • Radio link bandwidth • Object Size • End-user Throughput These four quantities are defined and described inSection 10.2 on page 232. Once familiar with the concepts in Section 10.2 on page 232, the reader should proceed to Section 10.3 on page 234, where the methodology for dimensioning GPRS/EGPRS cells is described. After that the reader is ready to use this methodology to dimension their GPRS/EGPRS network. Dependent of the below described network capability go to the relevant section: for Basic GPRS cells , this is a cell containing only B-PDCHs, i.e. MSs can use CS-1 to CS-2 coding schemes. Go to Section 10.5 on page 239. for GPRS cells , this is a cell containing B-PDCHs and/or G-PDCHs, i.e. MSs can use CS-1 to CS-2 coding schemes on B-PDCHs and CS-1 to CS-4 coding schemes on G-PDCHs. Go to Section 10.6 on page 246. for GPRS/EGPRS cells , this is a cell containing B-PDCHs and/or E-PDCHs, i.e. MSs can CS-1 to CS-2 coding schemes on B-PDCHs and use CS-1 to CS-4 and/or MCS-1 to MCS-9 coding schemes on E-PDCHs. Go to Section 10.7 on page 254. 10.2 Dimensioning Concepts 10.2.1 PDCH Utilization PDCH utilization is the filling factor for the allocated PDCHs. Each PDCH has the capacity to transmit 50 radio block downlink per second. A PDCH where the GPRS load is such that in average 30 radio blocks are transmitted per second is then said to have a PDCH utilization of 60% 232 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters The proposed way to measure this is to take a “snap shot” of the available BPCs and calculate the percentage of them that carry GPRS/EGPRS traffic at the time. Note: It is important to understand the difference between “(Average) PDCH Utilization” and “PDCH load (on active PDCHs)”. The “PDCH load” only considers active PDCHs, i.e. PDCHs that carry at least one TBF. The “PDCH load” measures the average number of active TBFs on active channels. Hence “PDCH load” is a number equal or greater than one (because there is minimum of one TBF on each active PDCH). In contrast, “PDCH Utilization” is the fraction of time a PDCH (or potential PDCH) is active (meaning carrying at least one TBF). This is a number between 0 (the PDCH is always idle) and 1 (the PDCH is always busy carrying data). A high PDCH utilization usually impacts the end-user throughput negatively. 10.2.2 Radio Link Bandwidth The Radio Link Bandwidth is the bandwidth one user would get if he was the only active user in the cell. The Radio Link Bandwidth is determined by the Radio Link Bit rate per PDCH and the MS Multislot class. Example: • Radio link bit rate is 10 kbps • MS supports 3 timeslots in downlink. then the radio link bandwidth is 3 x 10 = 30 kbps in downlink. 10.2.3 Object Size The object size is the size (in kBytes) of objects downloaded to the client. One object can be an e-mail, a data file (FTP) or a component of a web page, e.g. an image, a text string or a background frame. Experience and simulations show that the size of an object significantly impacts the end-user throughput with which the object can be downloaded. Normalized with respect to object size, small objects are slower to download than larger objects. Therefore performance graphs (Section 10.4 on page 235) show three different scenarios with object sizes 5kB, 20kB and 50kB respectively. Which combination of graphs to use in the dimensioning process depends on the traffic type. Table 13 5 kbyte Recommended Mapping From Applications to Object Sizes. MMS WAP WWW X X X 216/1553-HSC 103 12/16 Uen E | 2010-11-10 FTP E-mail withou t attachment E-mail with attachment X 233 User Description, Radio Network Statistics 20 kbyte X 50 kbyte 10.2.4 X X X X X End-User Throughput The end-user throughput is the throughput an end user experiences when using TCP/IP based applications. ObjectSizeonIPLevel EndUserThp = T (object completely received in client) 0 T (object start to leave server) [kbit=s] Equation 116 10.3 Definition for End-User Throughput How to Dimension a Network A number of simulations have been performed to obtain the graphs in Section 10.4 on page 235. By combining the simulation results with network information from the STS counters, a median end-user throughput can be estimated for a cell. There are 4 variables in the graphs: • Object size (which graph to use) • median end—user throughput [kbps] (vertical axis) • average radio link bandwidth [kbps] (which curve to use) • PDCH utilisation [ratio 0–1], where 1 indicates that the PDCHs are utilised to 100% (horizontal axis). If three of the variables are known then the fourth can be derived. E.g. for GPRS users: • the mapped object size is 20 kbyte and Figure 13 should be used. • the average radio link bandwidth is collected from STS counters and a suitable curve is chosen in the graph • the PDCH utilisation of PDCHs in the cell is collected from the STS counters and a suitable point on the horizontal axis is chosen. then an estimate of the median end-user throughput can be read off on the vertical axis. 234 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters 10.4 Simulation Results Presented in Graphs The throughput is presented on an end-to-end level, including higher protocol levels such as TCP. As a consequence the results vary depending on the characteristics of the data objects transferred. In order to describe this accurately, results for three different application object sizes are presented. If the feature Persistent Uplink Scheduling is active the round trip time for 3GPP release 4 mobiles is significantly better and the throughput is therefore higher than in the graphs below. This has most impact on the throughput for small size application objects. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 235 User Description, Radio Network Statistics Object size: 5 kbyte Median end-user throughput (kbps) 80 70 60 180kbps 160kbps 50 40 30 20 10 140kbps 120kbps 100kbps 80kbps 60kbps 40kbps 20kbps 10kbps 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 PDCH utilisation Figure 12 236 The Median End-User Throughput V.S. the PDCH Utilization for 5 Kbytes Application Objects. Each Line Represents a Specific Average Radio Link Bandwidth. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters Object size: 20 kbyte Median end-user throughput (kbps) 140 130 120 110 180kbps 100 160kbps 90 140kbps 80 70 100kbps 120kbps 60 80kbps 50 60kbps 40 40kbps 30 20 20kbps 10 10kbps 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 PDCH utilisation Figure 13 0.8 0.9 The Median End-User Throughput V.S. the PDCH Utilization for 20 Kbytes Application Objects. Each Line Represents a Specific Average Radio Link Bandwidth. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 237 User Description, Radio Network Statistics Object size: 50 kbyte 180kbps 160kbps Median end-user throughput (kbps) 160 150 140 130 120 110 100 90 80 70 60 50 40 30 20 10 0 0.1 0.2 Figure 14 238 140kbps 120kbps 100kbps 80kbps 60kbps 40kbps 20kbps 10kbps 0.3 0.4 0.5 0.6 0.7 PDCH utilisation 0.8 0.9 The Median End-User Throughput V.S. the PDCH Utilization for 50 Kbytes Application Objects. Each Line Represents a Specific Average Radio Link Bandwidth. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters 10.5 Adjust Cells with Only B-PDCHs There are two tracks to follow to achieve the goals set for a median end-user throughput for PS traffic: 10.5.1 • Adjust PDCH utilisation • Adjust average radio link bandwidth PDCH Utilisation The PDCH utilization depends primarily on traffic load (CS & PS) and HW configuration (number of TRXs). In addition there is a set of parameters. 10.5.1.1 Controlling Parameters • TBFDLLIMIT • TBFULLIMIT • PILTIMER • FPDCH • SPDCH For more information about the parameters, see Reference [20]. 10.5.1.2 STS Counters To get the actual PDCH utilization in the network the following counters should be used. • DLACTBPDCH, see Section 6.10 on page 138. • TRAFFDLGPRSSCAN, Section 6.10 on page 138. • ULACTBPDCH, see Section 6.10 on page 138. • TRAFFULGPRSSCAN, Section 6.10 on page 138. • TFTRALACC, see Section 5.3 on page 36. • THTRALACC, see Section 5.3 on page 36. • TFNSCAN, see Section 5.3 on page 36. • THNSCAN, see Section 5.3 on page 36. • TAVAACC, see Section 5.3 on page 36. • TAVASCAN, see Section 5.3 on page 36. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 239 User Description, Radio Network Statistics 10.5.1.3 Formulae P DCH (Utilisation) = Equation 117 Downlink PDCH Utilization P DCH (Utilisation) = Equation 118 DLACT BP DCH =P DCH (Available) T RAF F DLGP RSSCAN ULACT BP DCH =P DCH (Available) T RAF F ULGP RSSCAN Uplink PDCH Utilization P DCH (Availible) = P DCH (Dedicated) + P DCH (OnDemand) P DCH (On 0 Demand)= T CH 0 CS (Served T raffic) T F T RALACC T HT RALACC + CS (Served T raffic) = Cell 2 3 T HNSCAN T F NSCAN T AV AACC 0 F P DCH T CH = T AV ASCAN Equation 119 Note: 10.5.1.4 Number of BPC Available for the PS Domain if TBFDLLIMIT& TBFULLIMITis set higher than 10 (1.0), then BSS is a bit restricted to utilize all available BPCs as PDCHs. If TBFDLLIMIT& TBFULLIMIT>10 (1.0), then PDCHAvailable is overestimating the actual number of available PDCHs. If TBFDLLIMIT& TBFULLIMITis set high, e.g. 60 (6.0), then a better estimation for PDCHAvailable would be the value of ALLPDCHACC/ALLPDCHSCAN, see .Section 6.12 on page 149 Adjust PDCH Utilization There are seven ways to reduce the PDCH Utilisation: 1 Action: Lower the values of TBFDLLIMIT& TBFULLIMIT. Effect: This lowers the traffic threshold for the system to allocate OPDCHs, i.e. the number of OPDCHs increases. Note that it will not decrease PDCHAvailable, it will just make the estimate more accurate. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171 2 240 Action: Increase the value of PILTIMER. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters Effect: After the last TBF is released on an OPDCH the OPDCHs is kept allocated longer before it is returned to the CS domain. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171. 3 Action: Increase FPDCH and/or SPDCH. Effect: Protect GPRS against CS preemption, i.e. more dedicated PDCHs in the cell. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 4 Action: Change the setting of the PDCHPREEMPTpa rameter. Effect: Protect GPRS against CS preemption. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 5 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Action: Offload cell from voice traffic, see User Descriptions: • Reference [14] • Reference [16] 241 User Description, Radio Network Statistics • Reference [27] • Reference [11] • Reference [30] • Reference [26] Effect & Verification: This action can be verified with a decreased CSServed Traffic in the cell, see Equation 117. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, seeSection 5.4.8 on page 45. 6 Action: Redistribute GPRS traffic, see Reference [19] Effect & Verification: This action can be verified with the second-level traffic load counters described in Section 6.10 on page 138. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160 and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 7 Action: Increase the number of TRXs in the cell. Effect: Increasing the number of BPC available for OPDCHs. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL and FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171. 10.5.1.5 PS Traffic If the PS-traffic is increased or forecast to be increased, the PDCH utilization will go up if no action is taken, hence lowered “median end—user throughput”in the cell. The history of the “xy”GDATA (see Section 6.3 on page 99) counter values can indicate a tendency how the PS data is increasing/decreasing on cell level. 242 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters 10.5.2 Average Radio Link Bandwidth 10.5.2.1 STS Counters To get the current Average Radio Link Bandwidth in the network use the STS counters for CS-1/2 transfers as described in Section 6.9 on page 124. 10.5.2.2 Adjust Average Radio Link Bandwidth The only way to improve the average radio link bandwidth is to generally improve the C/I. 10.5.3 Example of Dimensioning a Cell with Only B-PDCHs Task: The quality requirement is that the time to deliver from the server to the MS an MMS of size 30 kB shall take no longer than 8 seconds (median value). Note that in addition to the 8 seconds the end-user will experience an additional delay due to MMS signalling and handshakes. This is typically a few RTTs (Round trip times) and depends on the MMS set-up. This additional delay is outside the scope of this document. Present Configuration: • One TRX cell with combined BCCH/SDCCH • FPDCH=1 (one dedicated PDCH in the cell) • Coding scheme used: CS-2 • MMS users primarily using 4-slot mobiles • (CS12DLACK)/(CS12SCHED*20 ms) = 10 kbps (average radio-link bit rate per PDCH) • TFTRALACC/TFNSCAN=2.2 Erlang traffic in the cell • THTRALACC/THNSCAN=0 • DLACTBPDCH/TRAFFDLGPRSSCAN = 1.6 (Average number of PDCHs carrying at least one activeTBF) • 1. Radio-link bandwidth = 4x10 kbps = 40 kbps • 2. Anticipated GPRS load: (DLACTBPDCH/TRAFF DLGPRSSCAN)x1.5 = 2.4 (50% anticipated volume increase due to MMS) STS information: Workflow: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 243 User Description, Radio Network Statistics 244 • 3. From quality requirement: Required throughput = 30kByte/8 seconds = 30 kbps. • 4. Which graph to use, 20kB or 50kB? The requirement is on MMSs with object size 30 kByte which is closer to 20 than to 50. Hence use graph with Object Size = 20kByte. • 5. Using the graph in the figure below, follow the curve corresponding to Radio Link Bandwidth of 40 kbps. Using this curve the requirement of 30 kbps translates into a PDCH Utilization of no more than 0.4 (40%). • 6. From the anticipated load (1) and the required PDCH Utilization (5) we get the minimum required number of PDCHs in the cell = 2.4/0.4 PDCHs = 6 PDCHs. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters Object size: 20 kbyte ------------------------ Median end-user throughput (kbps) 140 130 120 110 180kbps 100 160kbps 90 140kbps 80 70 100kbps 120kbps 60 80kbps 50 60kbps 40 40kbps 30---------------------------30 20 20kbps 10 10kbps 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.4 PDCH utilisation Figure 15 The Requirement of 30 kbps Translates into a PDCH Utilization of No More than 0.4 (40%). 216/1553-HSC 103 12/16 Uen E | 2010-11-10 245 User Description, Radio Network Statistics The conclusion is that to meet the anticipated traffic growth with required GPRS quality, then at least an average of 6 PDCHs must be available in the cell. With the present configuration, average 4.8 PDCHs are available (TFTRALACC/TFNSCAN = 2.2 and one TRX) . There are three options to get the required average 6 PDCHs in the cell: a) Offload the cell from voice traffic to get TFTRALACC/TFNSCAN = 1 or lower. b) Dedicate 6 FPDCHs in the cell (not a realistic option) c) Expand the cell with a second TRX As a final note we can see that if no action is taken, the anticipated traffic growth will generate channel load of 50% (average 2.4 active PDCHs with average 4.8 PDCHs available). From the graph this would correspond to a median end-user throughput of 27 kbps, a download time of 8.9 seconds of the 30kByte MMSs. 10.6 Adjust Cells with B-PDCHs and G-PDCHs There are two tracks to follow to achieve the goals set for a median end-user throughput for PS traffic: 10.6.1 • Adjust PDCH utilization • Adjust average radio link bandwidth PDCH Utilization The PDCH utilization depends primarily on traffic load (CS & PS) and HW configuration (number of TRXs). In addition there is a set of parameters. 10.6.1.1 Controlling Parameters • TBFDLLIMIT • TBFULLIMIT • PILTIMER • FPDCH • SPDCH • NUMREQCS3CS4BPC For more information about the parameters, see Reference [20]. 246 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters 10.6.1.2 STS Counters To get the actual PDCH utilization in the network the following counters should be used. 10.6.1.3 • DLACTBPDCH, see Section 6.10 on page 138. • ULACTBPDCH, see Section 6.10 on page 138. • DLACTGPDCH, see Section 6.10 on page 138. • ULACTGPDCH, see Section 6.10 on page 138. • TRAFFDLGPRSSCAN, see Section 6.10 on page 138. • TRAFFULGPRSSCAN, see Section 6.10 on page 138. • TFTRALACC, see Section 5.3 on page 36. • THTRALACC, see Section 5.3 on page 36. • TFNSCAN, see Section 5.3 on page 36. • THNSCAN, see Section 5.3 on page 36. • TAVAACC, see Section 5.3 on page 36. • TAVASCAN, see Section 5.3 on page 36. Formulae PDCH (Utilisation) = Equation 120 Downlink Channel Utilization P DCH (Utilisation) = Equation 121 ULACT BP DCH + ULACT GP DCH =P DCH (Available) T RAF F ULGP RSSCAN ULACT BP DCH + ULACT GP DCH =P DCH (Available) T RAF F ULGP RSSCAN Uplink Channel Utilization P DCH (Available) = P DCH (Dedicated) + P DCH (OnDemand) P DCH (On 0 Demand)= T CH 0 CS (Served T raffic) T F T RALACC T HT RALACC + CS (Served T raffic) = Cell T F NSCAN 2 3 T HNSCAN T AV AACC 0 F P DCH T CH = T AV ASCAN Equation 122 Number of BPC Available for the PS Domain 216/1553-HSC 103 12/16 Uen E | 2010-11-10 247 User Description, Radio Network Statistics Note: 10.6.1.4 if TBFDLLIMIT& TBFULLIMITis set higher than 10 (1.0), then BSS is a bit restricted to utilise all available BPCs as PDCHs. If TBFDLLIMIT& TBFULLIMIT>10 (1.0), then PDCHAvailable is overestimating the actual number of available PDCHs. If TBFDLLIMIT& TBFULLIMITis set high, e.g. 60 (6.0), then a better estimation for PDCHAvailable would be the value of ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Adjust PDCH Utilization There are eight ways to reduce the PDCH Utilization: 1 Action: Lower the values of TBFDLLIMIT& TBFULLIMIT. Effect: This lowers the traffic threshold for the system to allocate OPDCHs, i.e. the number of OPDCHs increases. Note that it will not decrease PDCHAvailable, it will just make the estimate more accurate. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171. 2 Action: Increase the value of PILTIMER. Effect: After the last TBF is released on an OPDCH the OPDCHs is kept allocated longer before it is returned to the CS domain. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, Section 6.15 on page 160and Section 6.17.5 on page 171. 3 Action: Increase FPDCH and/or SPDCH. Effect: Protect GPRS against CS preemption, i.e. more dedicated PDCHs in the cell. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. 248 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 4 Action: Change the setting of the PDCHPREEMPTpa rameter. Effect: Protect GPRS against CS preemption. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 5 Action: Offload cell from voice traffic, see User Descriptions: • Reference [14] • Reference [16] • Reference [27] • Reference [11] • Reference [30] • Reference [26] Effect & Verification: This action can be verified with a decreased CSServed Traffic in the cell, see Equation 117. Cautions: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 6 Action: Redistribute GPRS traffic, see Reference [19]. Effect & Verification: This action can be verified with the second-level traffic load counters described in Section 6.10 on page 138. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 249 User Description, Radio Network Statistics Cautions: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 7 Action: Increase the number of TRXs in the cell. Effect: Increasing the number of BPC available for OPDCHs. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL and FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171. 8 Action: Increase NUMREQCS3CS4. Effect: Increase the ratio G-PDCH/B-PDCH. Verification: This action can be verified with the ChannelUtilisation measure, see Equation 122. Cautions: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL and FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171. 10.6.1.5 PS Traffic If the PS-traffic is increased, the PDCH utilization will go up. If no action is taken, this results in a lower“median end—user throughput”in the cell. The history of the “xy” GDATA (see Section 6.3 on page 99) counter values can indicate a tendency how the PS data is increasing/decreasing on cell level. 10.6.2 Average Radio Link Bandwidth 10.6.2.1 Controlling Parameters 250 • PDCHALLOC, see Reference [20]. • CHALLOC, see Reference [12]. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters 10.6.2.2 STS Counters To get the current Average Radio Link Bandwidth in the network the following counters are needed: 10.6.2.3 • The counters to calculate the average for CS-1/2 transfers and UL CS-1/2/3/4 transfers, seeSection 6.9 on page 124. • The interval counters for DL CS-1/2/3/4 transfers, INTXXGPRSTBF, see Section 6.9 on page 124. Adjust Average Radio Link Bandwidth There are three ways to improve the average radio link bandwidth: 1 Action: Generally improve the radio condition in the cell. Effect: Improved Radio Link Bit rate. Verification: This action can be verified with the counters listed in Section 6.9 on page 124. 2 Action: Change the initial coding scheme for DL, see Reference [23] Effect: Improved Radio Link Bit rate. Verification: This action can be verified with the counters INT”x”BRGPRSTBF. Cautions: Worse Radio Link Bit rate. 3 Action: Change settings of PDCHALLOC. Effect: Utilize the sparser frequency reuse for BCCH. Verification: This action can be verified with the counters listed in Section 6.9 on page 124. Cautions: Can contradict with settings of CHALLOC. 10.6.3 Example of Dimensioning a Cell with B-PDCHs and G-PDCHs Task: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 The quality requirement is that the time to deliver from the server to the MS an MMS of size 30 kB shall take no longer than 6.5 seconds (median value). Note that in addition to the 6.5 seconds the end-user will experience an additional delay due to MMS signalling and handshakes. This is typically a few RTTs (Round trip times) and depends on the MMS set-up. This additional delay is outside the scope of this document. 251 User Description, Radio Network Statistics Present Configuration: • One TRX cell with combined BCCH/SDCCH • FPDCH=1 (one dedicated PDCH in the cell) • MMS users primarily using 4-slot mobiles • Median value of INT”x”BRGPRSTBF = 14 kbps (average radio-link bit rate per PDCH) • TFTRALACC/TFNSCAN=2.2 Erlang traffic in the cell • THTRALACC/THNSCAN=0 • (DLACTBPDCH + DLACTGPDCH)/TRAFFDLGPR SSCAN = 1.92 (Average number of PDCHs carrying at least one active TBF) • 1. Radio-link bandwidth = 4x14 kbps = 56 kbps • 2. Anticipated GPRS load: ((DLACTBPDCH + DLACTGPDCH)/TRAFFDLGPRSSCAN)x1.5 = 2.88 (50% anticipated volume increase due to MMS) • 3. From quality requirement: Required throughput = 30kByte/6.5 seconds = 37 kbps. • 4. Which graph to use, 20kB or 50kB? The requirement is on MMSs with object size 30 kByte which is closer to 20 than to 50. Hence use graph with Object Size = 20kByte. • 5. Using the graph in the figure below, follow the curve corresponding to Radio Link Bandwidth of 56 kbps. Using this curve the requirement of 37 kbps translates into a PDCH Utilization of no more than 0.48 (48%). • 6. From the anticipated load (1) and the required PDCH Utilization (5) we get the minimum required number of PDCHs in the cell = 2.88/0.48 PDCHs = 6 PDCHs. STS information: Workflow: 252 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters Object size: 20 kbyte --------------------------- Median end-user throughput (kbps) 140 130 120 110 180kbps 100 160kbps 90 140kbps 80 70 100kbps 120kbps 60 80kbps 50 60kbps 40 37------------------------------------40kbps 30 20 20kbps 10 10kbps 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.48 PDCH utilisation Figure 16 The Requirement of 56 kbps Translates into a PDCH Utilization of No More than 0.48 (48%). The conclusion is that to meet the anticipated traffic growth with required GPRS quality, then at least an average of 6 PDCHs must be available in the cell. With the present configuration, average 4.8 PDCHs are available (TFTRALACC/TFNSCAN = 2.2 and one TRX) . There are three options to get the required average 6PDCHs in the cell: a) Offload the cell from voice traffic to get TFTRALACC/THNSCAN = 1 or lower. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 253 User Description, Radio Network Statistics b) Dedicate 6FPDCHs in the cell (not a realistic option) c) Expand the cell with a second TRX As a final note we can see that if no action is taken, the anticipated traffic growth will generate channel load of 60% (average 2.88 active PDCHs with average 4.8 PDCHs available). From the graph this would correspond to a median end-user throughput of 30 kbps, a download time of 8 seconds of the 30kByte MMSs. 10.7 Adjust Cells with B-PDCHs and E-PDCHs There are two tracks to follow to achieve the goals set for a median end-user throughput for PS traffic: 10.7.1 • Adjust PDCH utilization • Adjust average radio link bandwidth PDCH Utilization The PDCH utilization depends primarily on traffic load (CS & PS) and HW configuration (number of TRXs). In addition there is a set of parameters. 10.7.1.1 Controlling Parameters • TBFDLLIMIT • TBFULLIMIT • PILTIMER • FPDCH • SPDCH • NUMREQEGPRSBPC For more information about these parameter see Reference [20]. 10.7.1.2 STS Counters To get the actual PDCH utilization in the network the following counters should be used. 254 • DLACTBPDCH, seeSection 6.10 on page 138. • DLACTEPDCH, see Section 6.10 on page 138. • UACTLBPDCH, see Section 6.10 on page 138. • ULACTEPDCH, see Section 6.10 on page 138. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters 10.7.1.3 • TRAFFDLGPRSSCAN, see Section 6.10 on page 138. • TRAFFULGPRSSCAN, see Section 6.10 on page 138. • TFTRALACC, see Section 5.3 on page 36. • THTRALACC, see Section 5.3 on page 36. • TFNSCAN, see Section 5.3 on page 36. • THNSCAN, see Section 5.3 on page 36. • TAVAACC, see Section 5.3 on page 36. • TAVASCAN, see Section 5.3 on page 36. Formulae DLACTBPDCH =BPDCH (Available ) B 0 PDCH (Utilisation) = TRAFFDLGPRSSCAN Equation 123 Downlink B-PDCH Channel Utilization ULACTBPDCH =BPDCH (Available) B 0 PDCH (Utilisation) = TRAFFULGPRSSCAN Equation 124 Uplink B-PDCH Channel Utilisation DLACTEPDCH =EPDCH (Available) E 0 PDCH (Utilisation) = TRAFFDLGPRSSCAN Equation 125 Downlink E-PDCH Channel Utilisation ULACTEPDCH =EPDCH (Available) E 0 PDCH (Utilisation) = TRAFFULGPRSSCAN Equation 126 Uplink E-PDCH Channel Utilization 216/1553-HSC 103 12/16 Uen E | 2010-11-10 255 User Description, Radio Network Statistics If F P DCH smaller than N U M REQEGP RSBP C EP DCH (Available) E 0 P DCH (OnDemand) = 0 P DCH 0 P DCH F P DCH M AX 0 F P DCH ; T CH 0 CS (T raf f ic)] BP DCH (Dedicated) + BP DCH (OnDemand) BP DCH (Dedicated) (OnDemand) = Equation 127 = M IN [N U M REQEGP RSBP C (Available ) = : EP DCH (Dedicated) + EP DCH (OnDemand) EP DCH (Dedicated) B B = T AV AACC = 0 0 0 CS (T raf f ic) N U M REQEGP RSBP C ; 0 T AV ASCAN T F T RALACC T HT RALAC C CS (T raf f ic) = Cell + 2 3 T HN SCAN T F N SCAN T AV AACC T CH = 0 F P DCH T AV ASCAN Formulas to Be Used for Number of Available Bpcs for PS if There Are Less Dedicated PDCHs in the Cell than Maximum Allowed E-PDCHs. If FPDCH larger or equal to NUMREQEGPRSBPC: E-PDCHAvailable = E-PDCHDedicated + E-PDCH on-demand E-PDCHDedicated= NUMREQEGPRSBPC E-PDCHon-demand = 0 B-PDCHAvailable= B-PDCHDedicated + B-PDCH on-demand B-PDCHDedicated= FPDCH-NUMREQEGPRSBPC B-PDCHon-demand = TCH-CS Served Traffic CS Served Traffic = Ceil TFTRALACC __________ ( _________ + THTRALACC ) TFNSCAN TAVAACC TCH = __________ - 2*THNSCA N FPDCH TAVASCAN Figure 17 256 Formulas to Be Used for Number of Available Bpcs for PS if There Are More or Equal Dedicated PDCHs in the Cell than Maximum Allowed E-PDCHs. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters E 0 P DCH If F P DCH larger or equal to N U M REQEGP RSBP C (Available) = E E 0 P DCH 0 P DCH (Dedicated) + (Dedicated) = ( ) = : (On N U M REQEGP RSBP C 0 Demand ) ) = 0 ( ( Note: ) = CS (Served T raf f ic) = T CH = Equation 128 )+ ( ) ) = ( 10.7.1.4 0 P DCH E 0 P DCH On 0 Demand 0 P DCH Available B 0 P DCH Dedicated B 0 P DCH On 0 Demand B 0 P DCH Dedicated F P DCH 0 N U M REQEGP RSBP C B 0 P DCH On 0 Demand T CH 0 CS Served T raf f ic ( B E Ceil T F T RALACC ( + ) T HT RALAC C T F N SCAN 2 3 T HN SCAN T AV AACC 0 F P DCH T AV ASCAN Formulas to Be Used for Number of Available Bpcs for PS if There Are More or Equal Dedicated PDCHs in the Cell than Maximum Allowed E-PDCHs if TBFDLLIMIT& TBFULLIMITis set higher than 10 (1.0), then BSS is a bit restricted to utilize all available BPCs as PDCHs. If TBFDLLIMIT& TBFULLIMIT>10 (1.0), then PDCHAvailable is overestimating the actual number of available PDCHs. If TBFDLLIMIT& TBFULLIMITis set high, e.g. 60 (6.0), then a better estimation for PDCHAvailable would be the value of ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Adjust PDCH Utilization There are eight ways to reduce the PDCH Utilization: 1 Action: Lower the values of TBFDLLIMIT& TBFULLIMIT. Effect: This lowers the traffic threshold for the system to allocate OPDCHs, i.e. the number of OPDCHs increases. Note that it will not decrease PDCHAvailable, it will just make the estimate more accurate. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171. 2 Action: Increase the value of PILTIMER. Effect: After the last TBF is released on an OPDCH the OPDCHs is kept allocated longer before it is returned to the CS domain. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 257 User Description, Radio Network Statistics Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, Section 6.15 on page 160and Section 6.17.5 on page 171. 3 Action: Increase FPDCH and/or SPDCH. Effect: Protect GPRS/EGPRS against CS preemption, i.e. more dedicated PDCHs in the cell. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 4 Action: Change the setting of the PDCHPREEMPTpa rameter. Effect: Protect GPRS against CS preemption. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Caution: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 5 258 Action: Offload cell from voice traffic, see User Descriptions: • Reference [14] • Reference [16] • Reference [27] • Reference [11] • Reference [30] 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters • Reference [26] Effect & Verification: This action can be verified with a decreased CSServed Traffic in the cell, see Equation 117. Cautions: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 6 Action: Redistribute GPRS/EGPRS traffic, see Reference [19]. Effect & Verification: This action can be verified with the second-level traffic load counters described in Section 6.10 on page 138. Cautions: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL, FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171and blocking in the CS domain which can be seen with the counter CCONGS, see Section 5.4.8 on page 45. 7 Action: Increase the number of TRXs in the cell. Effect: Increase the number of BPC available for OPDCHs. Verification: This action can be verified with the counters ALLPDCHACC/ALLPDCHSCAN, see Section 6.12 on page 149. Cautions: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL and FAILMOVECELL, see Section 6.15 on page 160and Section 6.17.5 on page 171. 8 Action: Increase NUMREQEGPRSBPC. Effect: Increase the ratio E-PDCH/B-PDCH. Verification: This action can be verified with the Channel Utilisation measure, see Equation 127 or Figure 17. Cautions: Shortage of GSL devices. This can be seen with the counters ALLPDCHPCUFAIL and FAILMOVECELL, see Section 6.15 on page 160 and Section 6.17.5 on page 171. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 259 User Description, Radio Network Statistics 10.7.1.5 PS Traffic If the PS-traffic is increased, the PDCH utilization will go up. If no action is taken, this results in a lower“median end—user throughput”in the cell. The history of “xy” GDATA & “xy” EGDATA (see Section 6.3 on page 99) counter values can indicate a tendency how the PS data is increasing/decreasing on cell level. 10.7.2 Average Radio Link Bandwidth 10.7.2.1 Controlling Parameters 10.7.2.2 • PDCHALLOC, see Reference [20]. • CHALLOC, see Reference [12]. STS Counters To get the current Average Radio Link Bandwidth in the network the following counters are needed: 10.7.2.3 • The counters to calculate the averages for CS-1/2 transfers, UL CS-1/2/3/4 and EGPRS transfers, seeSection 6.9 on page 124. • The interval counters for DL CS-1/2/3/4 transfers, INTXXGPRSTBF, and DL EGPRS transfers, INTXXEGPRSTBF, see Section 6.9 on page 124. Adjust Average Radio Link Bandwidth There are four ways to improve the average radio link bit rate: 1 Action: Generally improve the radio condition in the cell. Effect: Improved Radio Link Bit rate. Verification: This action can be verified with the counters listed in Section 6.9 on page 124. 2 Action: Change the initial coding scheme for DL, see Reference [23] Effect: Improved Radio Link Bit rate. Verification: This action can be verified with the counters INT”x”BRGPRSTBF. Cautions: Worse Radio Link Bit rate. 3 Action: Change settings of PDCHALLOC. Effect: Utilise the sparser frequency reuse for BCCH. 260 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters Verification: This action can be verified with the counters listed in Section 10.7.2 on page 260. Cautions: Can contradict with settings of CHALLOC. 4 Action: Change the LQC settings for EGPRS TBFs, see Reference [14]. Effect: Improved Radio Link Bit rate. Verification: This action can be verified with the counters INT”x”BREGPRSTBF. Cautions: Worse Radio Link Bit rate. 10.8 Example of Dimensioning a Cell with Only E-PDCHs Task: The quality requirement is that the time to deliver from the server to the MS an MMS of size 30 kB shall take no longer than 4.3 seconds (median value). Note that in addition to the 4.3 seconds the end-user will experience an additional delay due to MMS signalling and handshakes. This is typically a few RTTs (Round trip times) and depends on the MMS set-up. This additional delay is outside the scope of this document. Present Configuration: • Two TRX cell with non-combined BCCH/SDCCH • FPDCH=3 (three dedicated PDCHs in the cell) • NUMREQEGPRSBPC=3 (maximum three E-PDCHs in the cell) • MMS users primarily using 2-slot EGPRS capable mobiles • Median value of INT”x”BREGPRSTBF = 40 kbps (average radio-link bit rate per PDCH) • TFTRALACC/TFNSCAN=5.8 Erlang traffic in the cell (2% blocking rate from Erlang B tables) • THTRALACC/THNSCAN=0 • DLACTEPDCH/TRAFFDLGPRSSCAN = 0.93 (Average number of PDCHs carrying at least one active TBF) • 1. Radio-link bandwidth = 2x40 kbps = 80 kbps STS information: Workflow: 216/1553-HSC 103 12/16 Uen E | 2010-11-10 261 User Description, Radio Network Statistics 262 • 2. Anticipated EGPRS load: DLACTEPDCH/TR AFFDLGPRSSCANx1.5 = 1.4 (50% anticipated volume increase due to MMS) • 3. From quality requirement: Required throughput = 30kByte/4.3 seconds = 56 kbps. • 4. Which graph to use, 20kB or 50kB? The requirement is on MMSs with object size 30 kByte which is closer to 20 than to 50. Hence use graph with Object Size = 20kByte. • 5. Using the graph in the figure below, follow the curve corresponding to Radio Link Bandwidth of 80 kbps. Using this curve the requirement of 80 kbps translates into a PDCH Utilization of no more than 0.35 (35%). • 6. From the anticipated load (1) and the required PDCH Utilization (5) we get the minimum required number of PDCHs in the cell = 1.4/0.35 PDCHs = 4 PDCHs. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GPRS/EGPRS Radio Network Dimensioning Using STS Counters Median end-user throughput (kbps) Object size: 20 kbyte --------------------------------------- 140 130 120 110 180kbps 100 160kbps 90 140kbps 80 70 100kbps 120kbps 60 80kbps 56------------------------50 60kbps 40 40kbps 30 20 20kbps 10 10kbps 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.35 PDCH utilisation Figure 18 The Requirement of 56 kbps Translates into a PDCH Utilization of No More than 0.35 (35%). The conclusion is that to meet the anticipated traffic growth with required EGPRS quality, then an average of 4 E-PDCHs should be available 216/1553-HSC 103 12/16 Uen E | 2010-11-10 263 User Description, Radio Network Statistics in the cell. With the present configuration 3 E-PDCHs are available (NUMREQEGPRSBPC=3 & FPDCH=3) . There are two main options to get more E-PDCHs in the cell: a) Increase NUMREQEGPRSBPC to 4, i.e. make it possible for BSS to allocate an on-demand E-PDCH. With this the blocking rate will remain at 2% for speech and the E-OPDCH will in average be available for EGPRS 98% of the time (1–GoS). The PDCH utilisation is then 1.4/(3+0.98)=0.352(35.2%) and the target is reached with remained quality for speech. b) Dedicate 4 PDCHs in the cell for EGPRS (NUMREQEGPRSBPC=4 & FPDCH=4), which will lead to an increased blocking rate of 3.7% for speech (not recommended). As a final note we can see that if no action is taken, the anticipated traffic growth will generate channel load of 47% (average 1.4 active PDCHs with average 3 PDCHs available). From the graph this would correspond to a median end-user throughput of 48 kbps, a download time of 5 seconds of the 30kByte MMSs. 264 216/1553-HSC 103 12/16 Uen E | 2010-11-10 GSM to UTRAN Performance Monitoring 11 GSM to UTRAN Performance Monitoring 11.1 Introduction This chapter details the performance measures available between GSM and UTRAN. 11.2 Monitoring GSM to UTRAN Handovers The number of handovers from a GSM cell to a UTRAN cell can be monitored. Note that only outgoing handovers from the GSM system are counted, similar counters exist in the UMTS system to count outgoing handovers to the GSM system. More information about GSM to UTRAN handovers can be found in Reference [24]. The counters are defined per cell relation. 11.2.1 Object Types and Counters Object type: NUCELLRELCNT HOVERCNTUTRAN The number of handover attempts to the neighboring UTRAN cell. HOVERSUCUTRAN The number of successful handovers to the neighboring UTRAN cell. HORTTOCHUTRAN The number of handover attempts to the neighboring UTRAN cell resulting in the MS returning to the old channel on the GSM cell. HOREQCNTUTRAN The number of handover required sent to the neighboring UTRAN cell. HOATTSHOULDUTRAN Number of handover attempts to a neighboring UTRAN cell when the MSC, with usage of the Service Handover Information Element, has indicated that a handover to UTRAN should be performed. URGHOVERUTRAN Number of handover attempts to the neighbor UTRAN cell in case of urgency conditions. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 265 User Description, Radio Network Statistics SUCURGHOUTRAN Number of successful handover attempts to the neighbor UTRAN cell in case of urgency conditions. 266 216/1553-HSC 103 12/16 Uen E | 2010-11-10 IP Transport Statistics 12 IP Transport Statistics 12.1 Introduction IP network statistics can be obtained from the BSC LAN switches in the BSC, and the STN on RBS site (Reference [37]). The following three types of traffic pass through the switch: • O&M traffic between the APG40/43, STOC, GPH and NMS • Gb/IP traffic between the GPH and SGSN • BSC internal Ethernet traffic between the GPH/PCU magazines • Abis over IP • Abis Optimization (in some configurations). For more details on IP connectivity in BSS, please see Reference [39]. The O&M traffic consist both of general management traffic and bulk transfers of data from the APG40/43. The purpose of this chapter is to give an overview of the capabilities of the switch and give a brief description of the technologies used. 12.2 SNMP Infrastructure The Simple Network Management Protocol (SNMP) is specified by IETF in a number of RFCs. The SNMP infrastructure consists of SNMP agents in the BSC LAN switches and an SNMP manager in the NMS. The SNMP agents access data that is stored in different Management Information Bases (MIBs) in the managed device. The MIBs contain scalar objects (single object instances) and tabular objects (lists of related objects). The managed objects contains information about the device, for example: • Static information like the name of the system. • Status information such as status about network interfaces or the temperature of the device. • Statistics about network traffic (counters) • Configuration information such as payload size, TTL values etc. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 267 User Description, Radio Network Statistics For more information on the structure of MIBs for TCP/IP based networks see RFC 1155. 12.3 IP Network Layers Network statistics can be obtained from the different layers of the network stack. TCP/IP networks, as used in the BSS, consist of the following layers: • Gb, SSH etc. (Application layer) • TCP/UDP (Transport layer) • IP (Network layer) • Ethernet (Datalink layer) Traffic passes down in the network stack from the application layer down to the datalink layer and is transferred to the next node in the network. When the data reaches its destination it traverses the network stack up to the application level. Network infrastructure uses addressing on the Ethernet layer (local switching) and Network layer (routing). Network statistics can be obtained on the Datalink, Network and Transport layers. The counters provide statistics on events applicable to the specific layers. 12.4 SNMP-Based Counters There are three SNMP MIBs that provide different types of network statistics: • MIB-II (RFC 1213) provides different types of system management information as well as statistics on higher level protocols such as IP, TCP, UDP etc. The counters provide information on different errors in the received packets as well as the number of received packets. • RMON ( RFC 1757) provide network statistics on Ethernet level and can be used to identify errors on the Ethernet level or to monitor network usage. RMON only gives information about the raw throughput on an interface and no information about higher level protocols. • sFlow (RFC 3176) is a more advanced statistics tool that takes samples of the traffic on the network layer which makes it possible to create statistics on different VLANs and IP hosts. This chapter gives a brief description of the content of the different MIBs and provides the names of the different counters to give an idea of the statistics available. 268 216/1553-HSC 103 12/16 Uen E | 2010-11-10 IP Transport Statistics See the RFCs referenced above are available from IETF at http://www.ietf.org for a complete description of the MIBs and the different counters. 12.4.1 MIB-II (RFC 1213) The switch supports RFC 1213, Management Information Base for Network Management of TCP/IP-based internets: MIB-II. The MIB contains statistics counters as well as configuration information and configurable control objects. Because of the lack of security in SNMP v1/v2 only control objects that could do limited damage if they were manipulated are included. The following groups are available in MIB-II: 12.4.1.1 • System: System information including name and location of the node. • Interfaces: Information about the nodes network interfaces such as network protocols, status, physical address and traffic statistics. • Address Translation (deprecated): The Address Translation group is deprecated but have been kept for backward compatibility with MIB-1. • The IP group: IP specific counters. • The ICMP group: ICMP specific counters. • The TCP group: TCP specific counters. • The UDP group: UDP specific counters. • The EGP group: EGP specific counters. • The Transmisson group: Information about the underlying media. • The SNMP group: SNMP specific counters. Counters in the IP Group ipInReceives ipInHdrErrors ipInAddrErrors ipForwDatagrams ipInUnknownProtos ipInDiscards ipInDelivers ipOutRequests ipOutDiscards ipOutNoRoutes ipReasmTimeout ipReasmReqds ipReasmOKs 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Counter Counter Counter Counter Counter Counter Counter Counter Counter Counter Counter Counter Counter 269 User Description, Radio Network Statistics ipReasmFails ipFragOKs ipFragFails ipFragCreates ipRoutingDiscards Counter Counter Counter Counter Counter The following counters can be helpful to diagnose network problems: 12.4.1.2 • ipInHdrErrors : The number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc. • ipOutNoRoutes : The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this `no-route' criterion. Note that this includes any datagarms which a host cannot route because all of its default gateways are down. Counters in the ICMP Group The following counters are available on the different ICMP packets received: icmpInMsgs Counter icmpInErrors Counter icmpInDestUnreachs Counter icmpInTimeExcds Counter icmpInParmProbs Counter icmpInSrcQuenchs Counter icmpInRedirects Counter icmpInEchos Counter icmpInEchoReps Counter icmpInTimestamps Counter icmpInTimestampReps Counter icmpInAddrMasks Counter icmpInAddrMaskReps Counter icmpOutMsgs Counter icmpOutErrors Counter icmpOutDestUnreachs Counter icmpOutTimeExcds Counter icmpOutParmProbs Counter icmpOutSrcQuenchs Counter icmpOutRedirects Counter icmpOutEchos Counter icmpOutEchoReps Counter icmpOutTimestamps Counter icmpOutTimestampReps Counter icmpOutAddrMasks Counter icmpOutAddrMaskReps Counter The following counter can be helpful to diagnose network problems: 270 216/1553-HSC 103 12/16 Uen E | 2010-11-10 IP Transport Statistics • icmpInDestUnreachs : The number of received ICMP destination unreachable packets received which indicates that another router failed to forward a packet to its destination. ICMP destination unreachable packets indicate that a host is unreachable, it could be down or a router could have faulty or missing routing information. Note that this indicates problems in other parts of the network, not in this device. 12.4.1.3 Counters in the TCP Group Note that instances of object types that represent information about a particular TCP connection are transient; they persist only as long as the connection in question. tcpActiveOpens Counter tcpPassiveOpens Counter tcpAttemptFails Counter tcpEstabResets Counter tcpCurrEstab Gauge tcpInSegs Counter tcpOutSegs Counter tcpRetransSegs Counter tcpInErrs Counter tcpOutRsts Counter 12.4.1.4 Counters in the UDP Group udpInDatagrams udpNoPorts udpInErrors udpOutDatagrams 12.4.2 Counter Counter Counter Counter RMON (RFC 1757) The switch has support for the RMON MIB (Remote Network Monitoring Management Information Base) according to RFC 1757. The RFC specifies nine groups that are all optional to implement. The switch has support for the following four groups: • Statistics • History • Alarm • Event All implemented groups must contain all objects as specified in the RFC. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 271 User Description, Radio Network Statistics 12.4.2.1 The Ethernet Statistics Group The ethernet statistics group contains statistics measured by the probe for each monitored interface on this device. These statistics take the form of free running counters that start from zero when a valid entry is created. This group currently has statistics defined only for Ethernet interfaces. Each etherStatsEntry contains statistics for one Ethernet interface. There is one etherStats entry for each monitored Ethernet interface on the device. etherStatsIndex INTEGER (1..65535) etherStatsDataSource OBJECT IDENTIFIER etherStatsDropEvents Counter etherStatsOctets Counter etherStatsPkts Counter etherStatsBroadcastPkts Counter etherStatsMulticastPkts Counter etherStatsCRCAlignErrors Counter etherStatsUndersizePkts Counter etherStatsOversizePkts Counter etherStatsFragments Counter etherStatsJabbers Counter etherStatsCollisions Counter etherStatsPkts64Octets Counter etherStatsPkts65to127Octets Counter etherStatsPkts128to255Octets Counter etherStatsPkts256to511Octets Counter etherStatsPkts512to1023Octets Counter etherStatsPkts1024to1518Octets Counter etherStatsOwner OwnerString etherStatsStatus EntryStatus 12.4.2.2 The History Control Group The history control group controls the periodic statistical sampling of data from various types of networks. The historyControlTable stores configuration entries that each define an interface, polling period, and other parameters. Once samples are taken, their data is stored in an entry in a media-specific table. Each such entry defines one sample, and is associated with the historyControlEntry that caused the sample to be taken. Each counter in the etherHistoryEntry counts the same event as its similarly-named counterpart in the etherStatsEntry, except that each value here is a cumulative sum during a sampling period. historyControlIndex INTEGER (1..65535) historyControlDataSource OBJECT IDENTIFIER historyControlBucketsRequested INTEGER (1..65535) historyControlBucketsGranted INTEGER (1..65535) historyControlInterval INTEGER (1..3600) historyControlOwner OwnerString historyControlStatus EntryStatus 272 216/1553-HSC 103 12/16 Uen E | 2010-11-10 IP Transport Statistics 12.4.2.3 The Ethernet History Group The Ethernet History group records periodic statistical samples from a network and stores them for later retrieval. Once samples are taken, their data is stored in an entry in a media-specific table. Each such entry defines one sample, and is associated with the historyControlEntry that caused the sample to be taken. This group defines the etherHistoryTable, for Ethernet networks. Counters in the Ethernet History Group: etherHistoryIndex INTEGER (1..65535) etherHistorySampleIndex INTEGER (1..2147483647) etherHistoryIntervalStart TimeTicks etherHistoryDropEvents Counter etherHistoryOctets Counter etherHistoryPkts Counter etherHistoryBroadcastPkts Counter etherHistoryMulticastPkts Counter etherHistoryCRCAlignErrors Counter etherHistoryUndersizePkts Counter etherHistoryOversizePkts Counter etherHistoryFragments Counter etherHistoryJabbers Counter etherHistoryCollisions Counter etherHistoryUtilization INTEGER (0..10000) 12.4.2.4 The Alarm Group The alarm group periodically takes statistical samples from variables in the probe and compares them to previously configured thresholds. If the monitored variable crosses a threshold, an event is generated. A hysteresis mechanism is implemented to limit the generation of alarms. This group consists of the alarmTable and requires the implementation of the event group. 12.4.2.5 The Event Group The event group controls the generation and notification of events from this device. This group consists of the eventTable and the logTable. 12.4.3 sFLOW (RFC 3176) sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 273 User Description, Radio Network Statistics The architecture and sampling techniques used in the sFlow monitoring system are designed to provide continuous site-wide (and network-wide) traffic monitoring for high speed switched and routed networks. The design specifically addresses issues associated with: • Accurately monitoring network traffic at Gigabit speeds and higher. • Scaling to manage tens of thousands of agents from a single point. • Extremely low cost agent implementation. The sFlow monitoring system consists of an sFlow Agent (embedded in a switch or router or in a stand alone probe) and a central data collector, or sFlow Analyzer. The sFlow Agent uses sampling technology to capture traffic statistics from the device it is monitoring. sFlow Datagrams are used to immediately forward the sampled traffic statistics to an sFlow Analyzer for analysis. The sFlow MIB differs from the MIB-2 and RMON MIB in that it doesn’t in itself provide statistics counters. Instead the MIB contains configuration parameters for the sFlow agent on how the sampling should be performed and where the samples should be sent. It is then up to the sFlow analyser to interpret the data. 12.5 Formulae 12.5.1 Ethernet Throughput The counter etherStatsOctets in the RMON MIB can be used as a reasonable estimate of ethernet utilization. If greater precision is desired, the etherStatsPkts and etherStatsOctets objects should be sampled before and after a common interval. The differences in the sampled values are Delta_Pkts and Delta_Octets, respectively, and the number of seconds in the interval is Interval. These values are used to calculate the throughput as follows: T hroughput = Equation 129 12.5.2 DeltaP kts 3 (96 + 64) + (DeltaOctets 3 8) [kbps] (Interval 3 1024) Ethernet Throughput Ethernet Utilization The Ethernet throughput formula could be extended to provide statistics on network utilization by dividing with the total bandwidth of the interface. The bandwidth of the interface can be extracted from the MIB-II. 274 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Concepts 13 Concepts Abis Upper The interface between STN and PGW. B-PDCH A Packet Data Channel used for the transfer of CS-1 to CS-2 packet data and control signalling. B-TCH Traffic Channel, which in the PSD is capable of carrying GPRS (CS-1 to CS-2) packet data. Channel Group (CHGR) A channel group is a group of frequencies within one cell. A frequency may only be in one channel group per cell. Channel groups are operator controlled and facilitate control over groups of frequencies in a cell. CHGR-0 contains BCCH and is defined automatically at cell definition. Channel set indicator The channel set indicator says if new channels are to be established or if the old channels should be kept. The channels may be kept at a resource level upgrade. CS Traffic Frame A CS traffic frame is a HDLC frame containing CS speech traffic (SAPI 10) or CS data traffic (SAPI 11). CSD The domain where circuit switched calls are handled (speech, data, signalling). Dedicated PDCH A PDCH permanently allocated in a cell by operator command. A dedicated PDCH cannot be PDCH preempted by the CSD, it may only be PDCH deallocated by operator command. Dual Band The ability to access both GSM 900 and GSM 1800 band. Dual transfer mode A mobile station in dual transfer mode has simultaneously a CS and a PS connection. The allocated radio resources are coordinated by BSS. EGPRS 216/1553-HSC 103 12/16 Uen E | 2010-11-10 EGPRS is an enhanced GPRS feature using EDGE modulation and coding schemes. EGPRS can have net bit rates up to 59.2 kbps per timeslot. 275 User Description, Radio Network Statistics Established Uplink TBF An uplink TBF is considered established when the MS has started to send data uplink and at least one RLC data block has been received by the BSC. E-PDCH A Packet Data Channel used for the transfer of EGPRS and GPRS CS-1 to CS-4 packet data and control signalling. E-TCH Traffic Channel, which in the PS-domain is capable of carrying GPRS/EGPRS. G-PDCH A Packet Data Channel used for the transfer of GPRS CS-1 to CS-4 data and control signalling. GPRS GPRS is a feature that makes it possible to send packet data over the GSM network with GMSK coding schemes (CS-1 to CS-4). GPRS can have net bit rates up to 21.4 kbps per timeslot. GPRS Attach An MS performs a GPRS Attach to the network in order to obtain access to the GPRS/EGPRS services. GPRS network operation mode This concept is valid also for EGPRS. The network may provide coordination of paging for CS and PS services in different ways depending on if the Gs interface is present or not. See Reference [20] chapter 4.2.6 “Allocation of the Master PDCH” for a detailed explanation of the different operation modes. GPRS paging message This message is used to page an MS supporting GPRS and/or EGPRS. 276 G-TCH Traffic Channel, which in the PSD is capable carrying GPRS (CS-1 to CS-4) packet data. Master PDCH A PDCH carrying the Packet Broadcast Control Channel and the Packet Common Control Channel. PS traffic can also be carried on the Master PDCH. The Master PDCH is a dedicated PDCH. MBWDL This parameter defines the maximum bandwidth in downlink. MBWUL This parameter defines the maximum bandwidth in uplink. Packet ABIS Common term used for the features 'Abis over IP' and 'Abis Optimization'. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Concepts PCU Responsible for all PDCH allocated channels. PS Traffic Frame A PS traffic frame is a HDLC frame containing PS traffic (SAPI 12). The PS traffic includes payload, signalling on PDCHs and P-GSL control traffic. PSD The domain where packet switched connections are handled (GPRS/EGPRS connections). The PSD is dependent on the CSD to provide it with channels usable for PS connections. PSD idle list A list of on-demand PDCHs not carrying traffic. PSET A set of PDCHs possible to use together for a Temporary Block Flow (TBF). A PSET can contain up to eight on-demand and/or (semi-)dedicated PDCHs. It is complete when no more PDCHs is possible to allocate in the TCHGRP due to the number of deblocked TCHs. Maximum one PSET can be allocated on the same TCHGRP. Selection indicator The selection indicator indicates whether dedicated or on-demand PDCHs are to be allocated. Semi-dedicated PDCH A semi-dedicated PDCH is a PDCH that is permanently allocated in a cell by operator command but not always activated. A semi-dedicated PDCH cannot be PDCH preempted, but it can be deallocated by operator command. SIU SIU is the hardware used to implement the STN for Macro base stations. STN The Site Transport Node for RBS, is the logical name for network equipment used by RBSs for IP RAN transport. TBF A PS connection, that can be either uplink or downlink. TBF limit The application parameters in the uplink or downlink direction for when new on-demand PDCHs are requested. The limits correspond to the average amount of TBFs on all PDCHs in a cell. They are however calculated separately for E-, G- and B-PDCHs. Thus if the TBF limit is exceeded for any type of PDCHs, only PDCHs of the same type will be requested. Used PDCH PDCH carrying a TBF, regardless if the TBFs are in Delayed Release Mode or Extended UL TBF Mode. 216/1553-HSC 103 12/16 Uen E | 2010-11-10 277 User Description, Radio Network Statistics 278 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Glossary Glossary 8-PSK 8-Phase Shift Keying EIT Ericsson Instant Talk AQM Active Queue Management EMR Enhanced Measurement Reporting BPC Basic Physical Channel ENIQ Ericsson Network IQ BRP Basic Recording Period FAS Frequency Allocation Support BSC Base Station Controller FR Full Rate BTS Base Transceiver Station GMSK Gaussian Minimum Shift Keying CeNA Cellular Network Analyzer GoS Grade of Service CER Channel Event Recording GPH GPRS Packet Handler CHGRP0 Channel Group zero GPRS General Packet Radio Service CLS Cell Load Sharing HCS Hierarchical Cell Structure CP Central Processor HR Half Rate CTR Cell Traffic Recording HSCSD High Speed Circuit Switched Data DCA Differential Channel Allocation ICM Idle Channel Measurements DTM Dual Transfer Mode IETF Internet Engineering Task Force EGPRS Enhanced General Packet Radio Service (aka EDGE) IHO Intra-cell Handover 216/1553-HSC 103 12/16 Uen E | 2010-11-10 IP Incremental Redundancy 279 User Description, Radio Network Statistics LA Link Adaptation OSS Operation and Support System LA Location Area PBCCH Packet Broadcast Control Channel LLC PDU Logical Link Control Packet Data Unit PCCCH Packet Common Control Channel LQC Link Quality Control PC Power Control LU Location Update PCU Packet Control Unit MCPA Multi Carrier Power Amplifier PDCH Packet Data Channel MCTR Multi Carrier Transmitter Receiver PFC Packet Flow Context MDB Management Information Base PS Packet Switched MIB Measurement Database PSD Packet Switched Domain MRR Measurement Result Recording PSET PDCH Set MS Mobile Station PTA P-GSL Timing Advance MSC Mobile Services Switching Center QoS Quality of Service for GPRS/EGRPS MTR Mobile Traffic Recording RA Random Access NCS Neighboring Cell Support RFC Request For Comments NMS Network Management Station RNO Radio Network Optimization NWS Network Statistics SDCCH Stand-alone Dedicated Control Channel OPDCH On-demand PDCH SNMP Simple Network Management Protocol 280 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Glossary SP Support Processor SQI Speech Quality Index SS Switching System STS Statistics and Traffic Measurement Subsystem TA Timing Advance TBF Temporary Block Flow TCH Traffic Channel TRC Transcoder Controller TRX Transceiver 216/1553-HSC 103 12/16 Uen E | 2010-11-10 281 User Description, Radio Network Statistics 282 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Reference List Reference List [1] BSC Object Types and Counters, (User Guide) [2] BSC/TRC and BSC Hardware Dimensioning Handbook, (Description) [3] BSS G10B Network Impact Report, (User Description) [4] Flow graphs for incrementing and decrementing selected STS counters, (User Guide) [5] Location Area Dimensioning Guideline the Ericsson GSM System, (User Description) [6] Performance Management, Traffic Recording (PMR) [7] Statistics and Traffic Measurement, ASN.1 FILE, (Printout Description) [8] Statistics and Traffic Measurement Subsystem on the APG40, (User Guide) [9] STFIOPFILE, (Printout Description) [10] User Description, BSS File Definitions - STS and Recording Functions, (User Description) [11] User Description, Cell Load Sharing, (User Description) [12] User Description, Channel Administration, (User Description) [13] User Description, Channel Allocation Optimization, (User Description) [14] User Description, Differential Channel Allocation, (User Description) [15] User Description, EGPRS Link Quality Control, (User Description) [16] User Description, Enhanced Multi-Level Precedence and Pre-emption Service, (User Description) [17] User Description, Flexible Abis, (User Description) [18] User Description, Frequency Optimization Expert (FOX), (User Description) [19] User Description, GPRS/EGPRS Cell Reselection, (User Description) [20] User Description, GPRS/EGPRS Channel Administration, (User Description) 216/1553-HSC 103 12/16 Uen E | 2010-11-10 283 User Description, Radio Network Statistics [21] User Description, GPRS/EGPRS Connection Control and Transfer, (User Description) [22] User Description, GPRS/EGPRS Quality of Service, (User Description) [23] User Description, GPRS Link Adaptation, (User Description) [24] User Description, GSM-UMTS-LTE Cell Reselection and Handover, (User Description) [25] User Description, Idle Channel Measurements, (User Description) [26] User Description, Idle Mode Behaviour, (User Description) [27] User Description, Locating, (User Description) [28] User Description, Measurement Result Recording (MRR), (User Description) [29] User Description, Neighbouring Cell List Optimization Expert (NOX), (User Description) [30] User Description, Overlaid/Underlaid Subcells, (User Description) [31] User Description, Event Based Applications, (User Description) [32] User Description, Speech Quality Supervision, (User Description) [33] User Description, Synchronized Radio Network Optimization Expert (SYROX), (User Description) [34] User Description, Tandem Free Operation, (User Description) [35] User Description, Voice Group Call Service, (User Description) [36] BSS IP RAN System Description, (User Description) [37] User Description, ABIS over IP, (User Description) [38] User Description, ABIS Optimization, (User Description) [39] User Description, PGW Load Distribution, (User Description) [40] User Description, Handover and Signalling Robustness, (User Description) [41] STN Performance Statistics, Description [42] BSS RADIO NETWORK KEY PERFORMANCE INDICATOR (KPI) GUIDELINE, (Guide Line) [43] User Description, Abis Local Connectivity, (User Description) [44] User Description, A-Interface over IP 284 216/1553-HSC 103 12/16 Uen E | 2010-11-10 Reference List [45] MCPA Guideline 216/1553-HSC 103 12/16 Uen E | 2010-11-10 285