Telechargé par Zouhir Allaoui

User Description Radio Network Statistic

publicité
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
Téléchargement