GSM Quality of Service KPIs

GSM B11
BSS B11 GSM Quality of Service

& Traffic Load Monitoring
TMO18096 D0 SG DEN I1.0 Issue 1
STUDENT GUIDE
All Rights Reserved Alcatel-Lucent 2010
All rights reserved Alcatel-Lucent 2010

Passing on and copying of this document, use and communication of its contents not
permitted without written authorization from Alcatel-Lucent

BSS B11 GSM Quality of Service & Traffic Load Monitoring - Page 1
Empty page
Switch to notes view!
GSM B11
BSS B11 GSM Quality of Service & Traffic Load Monitoring
This page is left blank intentionally

Terms of Use and Legal Notices

1. Safety
Warning
Switch
to notes
view!
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to wear
conductive jewelry while working on the products. Always observe all safety precautions and do not work on the equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (Marks) are the property of their respective holders, including Alcatel-Lucent. Users
are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning the Mark. The absence of
a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to change
without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No other use or
transmission of all or any part of this document is permitted without Alcatel-Lucents written permission, and must include all
copyright and other proprietary notices. No other use or transmission of all or any part of its contents may be used, copied, disclosed
or conveyed to any party in any manner whatsoever without prior written permission from Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or describes, and is
expressly prohibited from modifying the information or creating derivative works without the express written consent of AlcatelLucent.
3
GSM B11
All rights
reserved Alcatel-Lucent 2010
4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including lost profits,
lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel-Lucent has been advised
of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an endorsement, nor a
recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The information
contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some cases, due to
contractual limitations, certain compromises have been made and therefore some features are not entirely accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment and its
operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-Lucent
disclaims any warranties in connection with the products as used and described in the courses or the related documentation,
whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties, including warranties of
merchantability, non-infringement and fitness for a particular purpose, or arising from a course of dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed internet
connections, interruptions, any computer virus or any other technical defect, whether human or technical in nature
5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are governed by the
laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal Notices, or the application
thereof to any person or circumstances, is held invalid for any reason, unenforceable including, but not limited to, the warranty
disclaimers and liability limitations, then such provision shall be deemed superseded by a valid, enforceable provision that matches,
as closely as possible, the original provision, and the other provisions of these Terms of Use and Legal Notices shall remain in full
force and effect.

Blank Page
GSM B11

Course Outline
1.About
B11 GSM
QoS
Monitoring
This
Course
Course
outline
1. Introduction
3JK12191AAAAWBZZA
4. Topic/Section is Positioned Here
Technical support
2. Indicators Overview 3JK12192AAAAWBZZA
Course objectives
3. Call Establishment 3JK12193AAAAWBZZA

4. Communication
Phase Here
3JK12194AAAAWBZZA
1. Topic/Section
is Positioned
Xxx5. Handover Indicators 3JK12195AAAAWBZZA
Xxx
6. Directed Retry Indicators 3JK12196AAAAWBZZA
Xxx
7. RMS Indicators 3JK12197AAAAWBZZA
8. Traffic Indicators
3JK12198AAAAWBZZA
2. Topic/Section
is Positioned
Here
9. Case Studies 3JK12199AAAAWBZZA
3. Topic/Section
Positioned Here
10. Annexesis 3JK12200AAAAWBZZA
GSM B11

Course Outline [cont.]

GSM B11

Course Objectives
Welcome to BSS B11 GSM Quality of Service & Traffic Load Monitoring
Upon completion of this course, you should be able to:

During this training, the participant will learn how interpret counters and indicators of the Alcatel
BSS System, in NPO and in a protocol analyzer (K12).

By the end of the course, the participant will be able to interpret :
- Global indicators, in order to assess the general quality of the network
- Detailed indicators, in order to detect / identify / locate the main malfunctions
- Handover indicators, in order to quantify efficiency and reason of HO
- Directed retry indicators, in order to quantify efficiency of directed retry
- RMS indicators to ease radio optimization and fault detection
- Traffic indicators, in order to detect/predict overload and compute adequate cell dimensioning as
well as to understand how RTCH resources are used in the network
GSM B11

Course Objectives [cont.]

GSM B11

About this Student Guide

Conventions
used view!
in this guide
Switch to notes
Note
Provides you with additional information about the topic being discussed. Although
this information is not required knowledge, you might find it useful or interesting.
Technical Reference
(1) 24.348.98 Points you to the exact section of Alcatel-Lucent Technical Practices
where you can find more information on the topic being discussed.
Warning
Alerts you to instances where non-compliance could result in equipment damage or
personal injury.
GSM B11
Where you can get further information

If you want further information you can refer to the following:
Technical Practices for the specific product
Technical support page on the Alcatel website: http://www.alcatel-lucent.com

About this Student Guide [cont.]
10
GSM B11

Self-assessment of Objectives
Contract number :
At the end of each
Course title :
Please, return this
Client (Company, Center) :
Language Switch
:
section you will be asked to fill this questionnaire

sheet to the trainer at the end of the training
to notes view!
Number of trainees :
Dates from :
to :
Location :
Surname, First name :

Did you meet the following objectives ?
Tick the corresponding box
Please, return this sheet to the trainer at the end of the training
Instructional objectives
1
Yes (or
globally
yes)
No (or
globally
no)
To be able to XXX
2
11
GSM B11

Comments
Self-assessment of Objectives [cont.]

Instructional objectives
12
Yes (or
Globally
yes)
No (or
globally
no)
Comments
GSM B11
Other comments
Thank you for your answers to this questionnaire

Do not delete this graphic elements in here:
Section 1
B11 GSM QoS Monitoring
Module 1
Introduction
3JK12191AAAAWBZZA Issue 1
GSM B11

Section 1 Module 1 Page 1
Blank Page
112
B11 GSM QoS Monitoring Introduction

GSM B11 BSS B11 GSM Quality of Service & Traffic Load Monitoring
Document History
Edition
Date
Author
Remarks
01
29-June-2010
Xavier Pourtauborde
First edition, B11 MR1

Module Objectives
Upon completion of this module, you should be able to:
Explain what is QoS and Traffic Load monitoring of the BSS
Explain what are the information sources available for that purpose
113


Module Objectives [cont.]
114


Table of Contents
1 Monitoring the QoS of the BSS
Definition
Scope of Work
2 Monitoring the Traffic Load of the BSS
Definition
3 Information Sources Available
Observation Tools
Interface Trace
Example of Abis & A Traces
Example of Traces Post-Processing
Example of Drive-Test
Performance Measurement Counters
Exercise
Alcatel-Lucent BSS Counters
BSS Counter Example
Exercise
4 Introduction to K1205 PC Emulation
Usage
Measurement Scenarios Screen
Filter Configuration
Monitor Screen
Extract a Call
Call Extraction
115
Exercise
5 Indicators
Definition
BSS Indicators Definition (Alcatel-Lucent)
Typical KPI for BSS
Typical KPI for Drive-tests
Typical Thresholds
Typical KPI Report
6 Methodological Precautions
Objective
Network Element Aggregation
Global Indicator Validity
Time Period Aggregation
Exercise
Self-assessment on the Objectives
End of Module

Page
7
8
9
10
11
12
13
16
17
18
20
21
22
23
24
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
Table of Contents [cont.]

116


117


Definition
"Monitor" "network" "quality"

monitor = measure or ensure?
network = BSS? BSS+NSS? BSS+NSS+PSTN
quality = service (end-user) and/or system (technical)
But also detect, localize, diagnose outages

detect (decide according to thresholds)
localize (which cell, BSC, etc.)
diagnose: radio, BSS, TC problems
118


Scope of Work
Use all available tools at disposal to ensure:

Subscribers get good QoS
BSS equipments & interfaces are all running

efficiently (no alarms, no critical situation)
BSS Optimizers receive good inputs to enhance

the network
Management can characterize the network and

deploy operational teams accordingly
119


1 1 10


Definition
Measure the "quantity" of traffic handled by:

each equipment, each board
each interface
Analyze traffic characteristics

call, handover, location update, etc.
As input for dimensioning/architecture team
BSC
BTS
Circuit Core
Network
MSC/VLR
BTS
GGSN
GPRS
backbone
BSC
BTS
1 1 11
MFS
SGSN


IP
Network
1 1 12


Observation Tools
System Performances: OMC-R PM
(Performance Measurements)
Counters
GSM PM Files are located in the OMC-R: /alcatel/share/var/AFTR/APME/BSC
NPO
OMC-R
BTS
BSC
Circuit Core
Network
MSC/VLR
BTS
GGSN
GPRS
backbone
BSC
MFS
SGSN
BTS
cf. PM file snapshot in the comments
1 1 13

9153-RA OMC-R: Operation and Maintenance Center Radio.

9159 NPO: Network Performance Optimizer, replace NPA + RNO since B10 onwards.
Extract from a PM File in OBSYNT format, from 17:00 to 17:30.

IP
Network
Observation Tools [cont.]
NSS Performance: Core Network Counters

OMC-CS
BSC
BTS
Circuit
Core
Network
MSC/VLR
BTS
BSC
BTS
1 1 14
GGSN
GPRS
backbone
MFS
SGSN


IP
Network
Observation Tools [cont.]
Interfaces Traces: Capture messages through each interface

Post-Processing tool
Abis trace
Drive-tests
A trace
BSC
BTS
Circuit
Core
Network
MSC/VLR
BTS
BSC
BTS
1 1 15
GGSN
GPRS
backbone
MFS
SGSN


IP
Network
Interface Trace
Interface
Information source
Advantages
A Interface
Capture/decode signaling
between MSC and BSC-TC
(A or Ater MUX) with
"protocol analyzer"
(Wandel, Tektronix,
Gnnettest, etc.)
GSM standard, can be used for

arbitrage between manufacturers
Complete information (message
contents, time-stamp)
Possible detection of
User/MS/BSS/TC/NSS problems
High cost of equipment

Time consuming, "post mortem"
(installation of tool, file analysis)
Expertise needed for analysis
Low coverage (K1103/MA10: 8
COCs, K1205/MPA: 32 COCs
maximum!)
Large amount of data (>> 10 Mbytes
/hour/BSC)
Abis Interface
Capture/decode signaling
between BSC and BTS with
"protocol analyzer"
(Wandel, Tektronix,
Gnnettest, etc.)
Complete information (message

contents, time-stamp)
Possible detection of
User/MS/BSS/TC/NSS problems
Complete radio information
thanks to measurement messages
Downlink and uplink

Time consuming, "post mortem"
(installation of tool, file analysis)
Important expertise needed for
analysis
Very low coverage (A few RSLs, a
few cell(s))
Very large amount of data (>> 10
Mbytes/hour/BTS)
Air interface
Use trace MS to capture

signaling and signal
characteristics
Give precise location (x,y) of

problems
Give downlink radio information
Only way to localize a lack of
coverage
Only way to monitor competitor

Very time-consuming
Difficulty to perform a lot of calls
-> number of samples insufficient
-> only a few streets
No uplink
1 1 16
Drawbacks

A interface :
The main advantage of the A interface is to allow the detection of Call Setup failures either due to the User or to the NSS (or PSTN).
Some typical user failure causes are:
Some typical NSS failure causes are:
IMSI Unknown in VLR

IMSI Unknown in HLR
IMEI Not Accepted
PLMN Not Allowed
Service Option Not Supported
Requested Service Not Supported
Unassigned Number
Operator Determined Barring
User Alerting
Facility Not Subscribed
No Route to Destination
Normal Call Clearing
User Busy
Invalid Number Format
Call Reject
Interworking
Normal Unspecified
Temporary Failure
Resource Unavailable
Switching Equipment Congestion
Normal Unspecified
Recovery on Timer Expiry
Call Reject
Interworking
Protocol Error
Network Failure
Congestion
CAUTION: In order to assess the QoS of a BSS or some cells of a BSS, all N7 links between this BSC and the MSC must be traced. Indeed, as the
N7 signaling load is spread over all N7 links, signaling messages relating to one call can be conveyed on any of the active N7 links.
K1103 protocol analyzer can trace up to 8 COCs at the same time but on maximum 4 PCM physical links.
K1205 protocol analyzer can trace up to 32 COCs at the same time but on maximum 16 PCM physical links.
Abis interface : The main advantage of the Abis trace is to allow a detailed and precise assessment of the radio quality of a cell at TRX level.
Both DL and UL paths can be observed and compared.
Air Interface : The main advantage of the Air trace is to assiciate a radio quality measurements to a given geographical area of the network.
From B7 release, the RMS feature implemented in the BSS provides a good level of information allowing to reduce the number of Abis traces
and drive test to be done for radio network optimization.

Example of Abis & A Traces
K12 / K15 Protocol Analyzer
1 1 17


Example of Traces Post-Processing

Enter subscribers ID - Select time frame
< 3 seconds
to display
individual
activity
Detailed
visibility
on calls
& data
sessions
Visibility /
Services
Link to multi-interface
& protocol decoding for deep
investigation
Failing
Calls
highlighted
Customer complaint analysis
1 1 18


Example of Traces Post-Processing [cont.]

Location Update Failures per IMSI
Ven do
r
Ven do
r
Ven do
r
Ven do
r
Ven do
r
Ven do
r
Ven do
r
Ven do
r
Ven do
r
1 1 19

Quality of handsets depending on various indicators (drops, call setup failures, etc.)

Ven do
r
Ven do
r
Ven do
r
Ven do
r
Detailed call analysis shows that a group of subscribers

owning the same handset keep trying a LU every 2s
Ven do
r
Ven do
r
Ven do
r
Ven do
r
Ven do
r
View at BSC level
Best / Worst performing handsets
3 H an
ds e t 1
1 H an
ds e t 3
5 H an
ds e t 2
2 H an
ds e t 2
4 H an
ds e t 1
5 H an
ds e t 1
2 H an
ds e t 1
4 H an
ds e t 2
1 H an
ds e t 4
1 H an
ds e t 2
2 H an
ds e t 4
3 H an
ds e t 2
4 H an
ds e t 4
4 H an
ds e t 3
2 H an
ds e t 3
2 H an
ds e t 5
3 H an
ds e t 3
3 H an
ds e t 4
Abnormal level
of Location updates:
2 of biggest cities
particularly impacted
Example of Drive-Test
1 1 20


Performance Measurement Counters
Count "events" seen by sub-system, value reported periodically

+ Low cost: collected directly at OMC
+ Compact data: possibility to store counters for a complete network
- Raw information, having to be consolidated to be understandable
- Manufacturer's dependent: questionable/difficult to compare
- Weak to analyze other sub-systems
1 1 21

The main advantage of the BSS counters is to provide easily QoS data for permanent QoS monitoring.

Exercise
Draw the BSS PM counters flow on the chart

In which sub-system are the BSS QoS indicators computed and stored?
BSC
1 1 22
OMC-R
BSC
OMC-R
BSC
OMC-R


NPO
Alcatel-Lucent BSS Counters
Performance Management implementation

Easy and cost-effective way to monitor network and carried traffic
Principle:
For a given duration (granularity period) typically 1 hour or hour
To count pre-defined events occurring on the Abis or A interface, or internal
events.
Counters stored with breakdown per network component (i.e. cell)
About 1100 counters are available (only for GSM).

Action: Open the GSM PM Counters database (MS-ACCESS format)
1 1 23

Alcatel-Lucent has chosen to implement PM counters in the BSC and to increment them mostly on Abis interface
signaling messages.
Other suppliers may have chosen to increment them on A interface signaling messages or to implement them in
the BTS.
Therefore caution should be taken when interpreting QoS indicators value since some discrepancies may be
observed due to these possible choices.
In order to provide the operators with an easy and cost-effective way to monitor their network and carried
traffic, BSS manufacturers have implemented specific software features, called performance management.
The principle is to count for a given duration called granularity period (typically 1 hour) pre-defined events
occurring on the Abis or A interface, or internally. These counters are stored for each duration, with breakdown
per network component (i.e. cell).

BSS Counter Example
Counter Reference
Counter Name
1 1 24

All counters are described in PM Counters document.

Smallest element
for which the
counter is provided
BSS Counter Example [cont.]
ts available
At the end of the hour:

180 samples every 20s
Hourly value = SUM of
sample /180
15 ts
10 ts
5 ts
t
O 20 40 60 80
1 1 25

All counters are described in PM Counters document.

Exercise
Observation Means: find the best source of information.

Observation to be done
Best source
1 overall radio quality of 1 cell
Counters
2 monitor user failures

3 get average network quality
4 localize precise location of a radio pb
5 localize abnormal cell in a network
6 history of network quality for several weeks
7 compare networks quality
8 discriminate problems between BSS/NSS. BSS
and NSS from different providers.
9 In a building, one is thinking that an elevator is
inducing EM trouble, how to confirm?
10 Identify potential interfering cells of 1 cell
1 1 26

EM: Electro-Magnetic

Why
Type 31 : RMS
1 1 27


Usage
The trace done with K1205 can be read:

Directly on K1205 itself
On any PC Windows NT with dedicated emulation software
Practical exercises will be done during the course using this software
The following slides and exercises are here to teach you the basic skill
needed to operate the tool for A Interface decoding
1 1 28


Measurement Scenarios Screen
To
Toenter
enterinin
monitoring
monitoringmode
modeto
to
analyze
analyzethe
the
AAtrace
trace
To
Tofilter
filterthe
themain
main
GSM
protocols
GSM protocolsand
and
messages
messages
To
Toselect
selectbinary
binary
trace
tracefile
file
1 1 29

1. Start the K1205 Protocol Tester application.

2. In the Recording File box: click on the Open button and select the "PAIB29.rec" file.
3. Select all displayed N7 logical links (corresponding to 4 PCMs in this case).
4. Click on the Browse button and select gsm2_A.stk in the gsm2 sub-directory (corresponding to the GSM Phase 2
A interface protocol stack).
5. Click on OK.
6. Click on the Monitor box to display the content of the recorded trace.

Filter Configuration
Configure your filter to remove some messages

and protocols => Bypass Protocol Filter
and select:
ANNEX 4
SCCP Except UDT

Keep all DTAP
BSSM Except PAGIN
Select also all

Logical Links
1 1 30

The ANNEX 4 introduces some basics on the GSM protocol layers that will be traced for the A interface analysis.
UDT: Unit Data (for Signaling Control Point) Remove Paging information

Monitor Screen
To
Toextract
extract11call
call
Short
ShortView
View
11line
line//message
message
Frame
FrameView
View
Full
Fulldecoding
decodingofof
selected
selectedmessage
message
Packet
Packetview
view
Message
Messagecontent
content
ininhexadecimal
hexadecimal
1 1 31


Extract a Call
How to find a specific message?

Edit - Find (or ctrl + F3)
Select All Logical Links.
Choose the protocol.
Select the message studied.
Use F3 to find another same message.
How to extract a call from these traces?

Click on the Zoom button.
Select CC message (Connection Confirm).
And UnZoom + Zoom to get:
SLR: Source Location Reference
LR: Destination Location Reference
1 1 32

At call setup, the first signaling message on the A interface is sent by the BSC to the MSC in order to set up a
logical link (called SCCP connection) between the BSS and the NSS.
Both BSS and NSS entities choose a unique reference which has to be used by the other party to identify the SCCP
connection on which the messages are conveyed. Both BSS reference (xxx) and NSS reference (yyy) are
exchanged during the SCCP Connection Request and Connection Confirm phases. After that only the reference of
the other party is used.

Call Extraction
Then
1 1 33

Click on the Filter button and filter out all protocol layers and messages except:
all DTAP messages,
all BSSMAP messages except "Paging,
SCCP CR (Connection Request) and CC (Connection Confirm) messages.

Exercise
Use the tool to extract a few calls from file PAIB29.REC

1) Zoom on a CC message:
Find the definition of all messages in the Frame View.
2) Zoom on a CR message with LUREQ.
How to extract the complete call?
3) Use Find to extract a call with an ALERTING message.
Can you see the CC message? If not, Why?
1 1 34


5 Indicators Definition
1 1 35


BSS Indicators Definition (Alcatel-Lucent)
Formula of counters
Call_drop_BSS
RTCH_Erlang_Total
=
=
=
=
(Drops BSS Int. Fail. + Drops BSS Remote TC)

(MC14c + MC739)
(Occupancy RTCH) / 3600
(MC380a + MC380b) / 3600
Difference: Key Performance Indicator (KPI) or Detailed Indicator

KPI: For high-level monitoring, to measure progress towards organizational
goals. KPI's are a subset of indicators, selected by radio engineers &
managers.
"If all KPIs are fine, then everything is fine"
Detailed: Any other indicator, within the 4000 ALU Indicators! For
troubleshooting and analysis of problems, known only by expert radio
engineers.
1 1 36


Typical KPI for BSS
Call drop %
Rate of calls dropped after successful assignment
E2E Call Set-Up Success % B11
Rate of call setups successfully
Outgoing Handover Success %
Rate of successful outgoing external and internal intercell SDCCH and
TCH handovers
TCH congestion %
Rate of RTCH not allocated during normal assignment due to congestion
on Air interface.
SDCCH unsuccess %
Rate of SDCCH not allocated during radio link establishment due to
congestion, radio problems or other problems.
1 1 37


Typical KPI for Drive-tests
Call Establishment Success Rate
Rate of DL RxQual samples < 3
Rate of DL RxLev samples > -80dBm (beware of power control)
Voice Quality (MOS)
1 1 38


Typical Thresholds
Not taking into account coverage or frequency planning

% Call Drop
1.50%
% RTCH drop
1.20%
% Call Setup Success (ALU formula)
97.0%
% RTCH Assign Cong
2.0%
% RTCH Assign Fail
1.5%
% SDCCH Drop
0.5%
% SDCCH Assign Cong
1.0%
% Out HO Efficiency
96.0%
1 1 39

The Call Drop rate at network level has to compared to:
Contractual threshold: can be requested by the operator management to the operational radio team, can be
requested by the operator to the provider on swap or network installation
Quality threshold: fixed internally by radio team management.
Quality thresholds are usually tighter than contractual ones.

Typical KPI Report
Observe this report from NPO. Is this cell below typical CSSR threshold?
Call success - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) - 01/07/2009 To 07/07/2009
(Working Zone: Training - Medium)
900
Call setup is above 97%

100.%
800
99.5%
700
Assign Unsucc
600
SDCCH drop
%
nb
Call drop
99.%
500
400
98.5%
300
% End to End Call setup

% Call success
% Call setup
200
98.%
100
0
97.5%
01/07/2009 02/07/2009 03/07/2009 04/07/2009 05/07/2009 06/07/2009 07/07/2009
1 1 40


1 1 41


Objective
Avoid typical errors regarding indicators interpretation
Rule: Good indicator value
Ex:
all componants are good
a BSC with CDR = 1% not all cells in the BSC are good !
a Cell with CSSR = 99% for one day not all hours are good !
1 1 42


Network Element Aggregation
cell 1
cell 2
cell 3
cell 4
cell 5
cell 6
cell 7
cell 8
cell 9
cell 10
number of calls number of call drop call drop rate

390
8
2,10%
546
29
5,25%
637
20
3,10%
1029
12
1,14%
536
3
0,50%
2
1
50,00%
3
1
33,00%
210
4
2,11%
432
5
1,20%
321
4
1,11%
average of cell results

total nb of drop/total number of calls
The average value of an indicator for a Network:

Is not the average of cell results (or any sub-part of it)
BUT is the average weighted by the traffic
1 1 43


9,95%
2,10%
Global Indicator Validity
To be reliable, an indicator must be based on a sufficient number of

events. Estimation theory gives a fresh look on our KPI:
If displayed CDR = 2%, but
nb of calls =
Nb Calls
Max
Min
10
10.7%
0.0%
100
4.7%
0.0%
200
3.9%
0.1%
400
3.4%
0.6%
600
3.1%
0.9%
1000
2.9%
1.1%
2000
2.6%
1.4%
3000
2.5%
1.5%
5000
2.4%
1.6%
10000
2.3%
1.7%
If a sample (number of calls) is too small, then the indicator doesn't represent
a statistical reality but just a random occurrence of events.
1 1 44

if p is the probability of success for a complete population
if one is measuring the probability P based on a sample of size N
There is a probability of 95 % that p is between:
Example: for p = 90 % and N = 100 => [ 84,12% ; 95,88% ]
P +/- 1.96*[(p*(1-p))/n]
On Alcatel-Lucent QoS monitoring tool (MPM application on OMC-R, NPA or RNO), NEs (BSS, Cell or TRX) are
highlighted with bad QoS indicator value if enough corresponding events have been observed (called Validity
threshold).
Examples:
Cells with bad Call Drop rate will be highlighted if CDR > CDR_threshold and if the Number of Calls is greater than
the CDR Validity threshold.
Cells with bad Outgoing handover success rate will be highlighted if OHOSUR > OHOSUR_threshold and if the
Number of Outgoing Handovers is greater than the OHO Validity threshold.

Time Period Aggregation
TCH congestion rate at busy hour:

Weighted average of cell congestion at the busy hour of the network?
Weighted average of cell congestion rate for its specific busy hour?
congestion %
erlang
Cell A
time
BHa
Max traffic = Busy Hour

Congestion @ Busy Hour
Cell B
Max congestion
BHb
Cell C
BHc
BSC
max
1 1 45
bh
Busy Hour at BSC level

not the same as cells BH

Usually:
Cell Busy Hour = hour of the day where max TCH traffic (in erlang) is observed.
BSC Busy Hour = hour of the day where max TCH traffic (as the sum of the TCH traffic of all cells of the BSS) is
observed.

Exercise
Is
the conclusion given for each indicator right?
Indicator
Samples
(calls)
Call drop = 0,9% in your country
Conclusion
OK / NOK ?
2456435
All the cells have a good call

drop
NOK
Call setup success for cell 15, 145 = 99,5%
2315
There is a good call setup

success rate for cell 15, 145
In Paris: 2500 cells with 95% of call setup success

In the rest of France: 5000 cells with 98%
3267872
In France, call setup success=

97%
Call drop rate for BSS <<BSS_1>> = 1%
4500
The call drop for BSS_1 is good
Call drop for cell 156,13 = 5%
215
Cell 15, 13 has certainly a

trouble
For BSS 1, call drop of 2%

For BSS 2, call drop of 3%
4000
2000
LA = BSS1+BSS2 has a call drop

of 2.3%
MSC <<Stadium>> has a call setup success of 95%
15346
BSS1 belonging to MSC Stadium

has a call setup success of 95%
1 1 46


Please be reminded to fill in the form

Self-Assessment on the Objectives
for this module
The form can be found in the first part
of this course documentation
1 1 47


End of Module
Introduction
1 1 48


Section 1
Module 2
Indicators Overview
GSM B11

Blank Page
122
B11 GSM QoS Monitoring Indicators Overview

Document History
Edition
Date
Author
Remarks
01
29-June-2010
Xavier Pourtauborde
First edition B11 MR1

Module Objectives
Explain what is a detailed indicator and what are the different classifications
of the detailed indicators provided by the Alcatel-Lucent BSS
123


124


Table of Contents
Page

1 Indicators Reference Name
Description
2 Indicators Classification
BSS Counter Collection Mechanism
BSS Performance Measurement Types
Classification of GSM Indicators
Formalism of Telecom Procedures
SDCCH Traffic
TCH Traffic
QoS SDCCH
QoS RTCH
QoS Call Statistics
Handover Causes
Outgoing Handovers
Incoming Handovers
Intracell Handovers
Handover Statistics per Couple of Cells
End of Module
125


7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

126


127


B11
Description
Each QOS indicator has a unique REFERENCE NAME of 10 characters.
Family
Technology
Unit
Procedure
Type
Prefix
128
Joker
Sub-type

Tehnology: G (GSM), U (UMTS), W (WiMaX)

mandatory
optional
129


BSS Counter Collection Mechanism
Cumulative
The counter is incremented at the occurrence of a specific event.
Abis or A message, or internal event.
At the end of a collection period, the result is the sum of the events.
Inspection
Every 20 or 10 seconds, a task quantifies an internal resource status (usually
a table).
At the end of a collection period, the result is the mean value.
Observation
Set of recorded information about a telecom procedure (handover, channel
release, UL & DL measurements reporting).
Radio Measurement Statistics

Aggregation of all "Measurement Results" for a day and a TRX/Cell.
1 2 10


B11
BSS Performance Measurement Types

Type
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
18
19
25
26
27
28
29
30
31
32
33
34
35
110
180
Name
Traffic meas.
Resource availability meas.
Resource usage on CCCH meas.
Resource usage on SDCCH meas.
Resource usage on TCH meas.
TCH HO meas.
LapD meas.
X25 meas.
N7 meas.
SDCCH obs.
TCH meas. obs.
Internal HO obs.
Incoming external HO obs.
Outgoing external HO obs.
TCH observation
A interface meas.
SMS PP meas.
SCCP meas.
TCH outgoing HO per adj. meas.
2G TCH incoming HO per adj. meas.
SDCCH HO
Directed retry meas.
SMS CB meas.
Radio Measurement Statistics
Change of frequency band meas.
Electro-Magnetic Emission
Voice Group Call Services
IP transport
Overview meas.
2G Traffic flow meas.
1 2 11
Limitations
40 cells
40 cells
40 cells
40 cells
40 cells
40 cells
Since
15 cells
1 cell
15 cells
15 cells
15 cells
15 cells
40 cells
1 cell
B8
B9
B9
B11

A standard PM type can be activated for the whole network. It means that the related counters are reported for
all the Network Elements they are implemented on (TRX, CELL, N7 link, X25 link, LAPD link, Adjacency).
A detailed PM type can be activated only on a sub-set of the network. It means that the related counters are
reported only for a limited number of Network Elements:
40 cells per BSS for PM types 1, 2, 3, 4, 5, 6, 26, 29
15 cells per BSS for PM types 10, 12, 13, 14, 15
1 cell per BSS for PM types 11, 27
Counter numbering rules:
Cyz: cumulative or inspection counters in PM types 1, 2, 3, 4, 5, 6, 18, 19, 25, 26, 27, 28, 29, 30, 32, 180
Ly.z: cumulative counters in PM type 7 (L stands for LAPD link)
Xy.z: cumulative counters in PM type 8 (X stands for X25 link)
Ny.z: cumulative counters in PM type 9 (N stands for N7 link)
Syz: observation counters in PM type 10 (S stands for SDCCH)
Ryz:: observation counters in PM type 11 (R stands for Radio measurements)
HOyz: observation counters in PM type 12, 13, 14 (HO stands for HandOver)
Tyz: observation counters in PM type 15 (T stands for TCH)
RMSyz: cumulative counters in PM type 31 (RMS stands for Radio Measurement Statistics)
MCyz or MNy.z: cumulative counters in PM type 110 (M stands for Major)

Classification of GSM Indicators

GSM indicators
Traffic load
Global QoS
Resource
availability
Densification
techniques
Dynamic SDCCH
Directed retry
SDCCH availability
Concentric cells
RTCH availability
Multilayer /
Multiband
Network
A Channel
availability
Multiband
Handover
HO causes
Outgoing HO
SDCCH
SDCCH
Incoming HO
TCH
Intracell HO
SDCCH/TCH HO
RTCH
SCCP
Couple of cell
Inter-PLMN HO
Control Channels
Call statistics
1 2 12
3G to 2G HO


Formalism of Telecom Procedures

(start)
Telecom procedure
-REQUEST
no resource available
in BSC
- congestion
resource available
in the BSC
PREPARATION
phase
Telecom procedure
-whose channel is
ALLOCATED in BSC
channel activation
failure
channel activation
success
assignment/HO
execution failure
Telecom procedure
-ATTEMPT
the MS has seized
the channel
EXECUTION
phase
Telecom procedure
-SUCCESS
failure in channel
established phase
(end)
Success Rate =
Efficiency Rate
Unsuccessful Rate
Failure Rate
1 2 13
- BSS problem
- NSS problem
- radio link failure

- handover execution failure
(with or without reversion
to the old channel)
- BSS problem
- NSS problem
- radio link failure
- BSS problem
- NSS problem
(Success) / (Request)
=
(Success) / (Allocated)
=
(Preparation & Execution Failures) / (Request)
=
(Failure) / (Request)


SDCCH Traffic
Traffic Load and Traffic Model

SDCCH traffic
SDCCH Traffic
Traffic
Model
Global
Requests
Normal
Assignment
MS
Penetration Rate
Resource
Occupancy
Traffic
Dual Band
SDCCH
Erlang
Handover
Global
Traffic
Normal
Assignment
Traffic
MT
SDCCH Mean
Holding Time
Handover
Traffic
MO
Loc. Update
LU Follow on
IMSI Detach
SMS
Sup. Service
Call
Re-Estab
Call
Estab
Other
1 2 14

The Traffic model section includes indicators for:
number of SDCCH connection requests and successes (Immediate Assignment, HO).
distribution of SDCCH connection success (MO and MT connections versus all MO+MT connections, type of MO
connections versus all MO connection types).
The MS penetration rate section includes the indicator for percentage of multiband MS SDCCH access (except LU)
versus all MS SDCCH accesses.
The Resource occupancy section includes indicators for:
SDCCH traffic in Erlang.
average duration in seconds of SDCCH channel usage.

TCH Traffic
Traffic Load and Traffic Model

RTCH Traffic
TCH traffic
Speech Version
&
Channel Type
Resource
Occupancy
Traffic Model
REQUESTS
REQUESTS
Assign / HO / DR
FR, DR, DR/EFR, AMR, DATA
SUCCESS
Assign/ HO/ DR
ALLOCATIONS
FR, HR, EFR, AMR, DATA
SUCCESS
AMR / TFO
HO PER CALL
1 2 15
TCH
Erlang
Full Rate
Erlang
Blocking Peak
Half Rate
Erlang
Full Rate
Allocated
TCH
Multiband
Occupancy
Half Rate
Allocated
Full Rate
Mean TCH
Time

The Speech Version and Channel Type section includes indicators for:
distribution of TCH allocation requests (FR/DR/DR+EFR/AMR/DATA).
distribution of TCH allocation successes (FR/DR/DR+EFR/AMR/DATA).
rate of TCH AMR allocation successes.
rate of TFO calls versus all speech calls.
The Traffic model section includes indicators for:
number of TCH connection requests and successes (Normal Assignment, HO, DR).
rate of TCH allocation successes for HO+DR versus all TCH allocations (NA+HO+DR).
number of HOs per call.
The Resource occupancy section includes indicators for:
RTCH traffic in Erlang (FR+HR, FR, HR, multiband).
average duration in seconds of RTCH channel usage (FR+HR, FR, HR).
number of TCH FR allocations and number of TCH HR allocations.
rate of TCH HR allocations versus all TCH allocations (FR+HR).
TCH peak of blocking (TCH congestion time).

Half Rate
Mean TCH
Time
Ratio of
HR Traffic
QoS SDCCH
GLOBAL Quality of Service

SDCCH
SDCCH
Assignment Phase
/
Handover
Established
Phase
Congestion
Drop Rate
Unsuccess
Drop Radio
Radio
Failure
BSS Failure
Access Reject
Dynamic Allocation
1 2 16


Drop HO
Drop BSS
QoS RTCH
GLOBAL Quality of service

RTCH
Assignment Phase
/
Handover
Congestion
Global Radio
Congestion Level
Unsuccess
Radio
Failure
RTCH
Preemption
Phase
Queuing
Phase
Queue Length
Assign
Queued
Assign
Queuing Fail
BSS
Failure
PVI =1
Requests
Success
Queued
Success
Allocation
with / without
Preemption
Timeout
Normal
Assign.
Higher
Priority
Directed
Retry
1 2 17
Drop rate
Drop Radio
Drop HO
Queue Full
Assign
Queued
& Reject
PCI =1
Established
Phase
Success


Failure
Drop BSS
Preemption
QoS Call Statistics
GLOBAL Quality of service

Call statistics
Call Statistics
Call Drop
Call Success
End to End
Call Setup
Success Rate
Call Setup
Success Rate
Call Drop Rate
Call Drop
End User Rate
Call
Success Rate
Cell Quality
Factor Absolute
Drop Radio
Drop HO
Cell Quality
Factor Relative
Drop BSS
Preemption
Transcoder
Failure
BSS Internal Failure
1 2 18


Handover Causes
Handover STATISTICS
Handover causes
Handover causes
HO causes per Adjacency
HO causes
All
HO
cause
distribution
Outgoing HO
Incoming HO
HO cause
category
distribution
HO cause
category
distribution
HO standard
cause
distribution
Fast traffic HO taken into account type of counter for dual band HO
1 2 19


Outgoing Handovers
Handover STATISTICS
Outgoing handovers
Outgoing HO
Intra-BSC
External
Intra-BSC & External
Preparation Success Rate
Success Rate
Efficiency
Efficiency
Efficiency
Call Drop Rate
Call Drop Rate
Call Drop Rate
Failure With Reversion
LAPD counter to analyze the cause of delay in HO procedures

1 2 20


Incoming Handovers
Handover STATISTICS
Incoming handovers
Incoming HO
Intra-BSC
External
Intra-BSC & External
Efficiency
Efficiency
Efficiency
Congestion
Congestion
Failure Radio
Failure No CIC
Failure BSS
Failure Radio
Incoming external HO 3G - > 2G
Failure BSS
Incoming external HO 2G - > 2G only

1 2 21


Intracell Handovers
Handover STATISTICS
Intracell handovers
Intracell HO
Efficiency
Congestion
New B9 counters: HO Cause 30

NB_TCH_HO_REQ_30_ReturnCSZone
=MC480 (Type 110)
NB_TCH_HO_ATPT_30_ReturnCSZone
=MC481 (Type 110)
Call Drop Rate

CDR Radio
CDR BSS
Failure BSS
1 2 22


Handover Statistics per Couple of Cells
Handover STATISTICS
Handover statistics per couple of cell
HO statistics
per Couple of Cell
Efficiency
Success Rate
HO Success Distribution
1 2 23



for this module
1 2 24


End of Module
Indicators Overview
1 2 25


Section 1
Module 3
Call Establishment
GSM B11

Blank Page
132
B11 GSM QoS Monitoring Call Establishment

Document History
Edition
Date
Author
Remarks
01
28-june-10
Xavier Pourtauborde
First edition B11 MR1

Module Objectives
Explain what is a Global indicator and what are the main BSS indicators
regarding GSM services provided by the Alcatel-Lucent BSS
133


134


Table of Contents
1 Call Setup Principles
Objective
Call Setup Procedure 1/2
Call Setup phasing
Paging
Successful Paging Procedure
Paging Discarded due to PCH Congestion
Paging Coordination
Paging Request, Air Interface
2 Typical Call Setup Failures
RLE Originated Call Success
RLE Terminated Call Success
RLE - Channel Request Message
RLE Call Distribution
RLE - SDCCH Congestion Failure
RLE - SDCCH Congestion
RLE - SDCCH Cong. Impacts
RLE - SDCCH Cong. Causes & Solutions
RLE Dynamic SDCCH
RLE - SDCCH Radio Failure
RLE
- Real SDCCH Radio Failures
135
RLE
- Ghost
RACH
B11 GSM QoS
Monitoring Call
Establishment
RLE - Ghost RACH Causes
RLE Same BCCH-BSIC couple (Channel Req.)
RLE Same freq-BSIC couple (HO Access)
RLE - BSS Failure
RLE - Summary
RLE - Indicators
Convention
SDCCH Phase Originated Call Success
SDCCH Phase Terminated Call Success
SDCCH Phase Location Update Success
SDCCH Phase - Drops
SDCCH Phase - Radio Drop
SDCCH Phase - BSS Drop
SDCCH Phase - HO drop
SDCCH Phase - Counters
SDCCH Phase - Indicators
SDCCH Phase - Exercise
TCH Assignment Success Case
TCH Assignment Phase Split
TCH Assignment MS Capabilities
TCH Assignment - Congestion
TCH Assignment Exercise
TCH Assignment - Radio Failure in TCH Uplink
TCH Assignment - Radio Failure in TCH Downlink
TCH Assignment - Radio Failure at T3107 expiry
TCH Assignment - BSS Problem
TCH Assignment - Counters
TCH Assignment - Indicators
TCH Assignment - Exercise
3 Key Performance Indicators
Reminder

Page
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
29
30
31
32
33
35
36
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

Page

SDCCH Congestion Rate
SDCCH Failure Rate
SDCCH Drop Rate
TCH Assign Unsuccess Rate
TCH Assign Unsuccess Rate Preparation Phase
TCH Assign Unsuccess Rate Execution Phase
Cell Congestion Rate
Call Setup Success Rate
Call Success Rate
End to End Call Setup Success Rate
Alc_Mono_Call
Differences between CSSR and E2ECSSR
End of Module
136


66
68
70
72
73
74
75
76
78
79
81
82
83
84
137


Objective
Description of the main call setup success and failures cases, with:
Main specific counters
Main protocol timers
Diagnose the main case of failures on A interface traces using the K1205
emulation software
138



MS
BSS
Call
CCCH
MSC/VLR
HLR/AuC/SCP/
Channel Request (RACH)

Immediate Assignment
(AGCH)
Establish Indication "CM Service Request"
MM Authentication Procedure
Setup
SDCCH
Phase
MM Identity Request
MM/RR Ciphering Procedure
Security Checks
MM/RR TMSI Reallocation Procedure

Subscription Checking
(calling party rights, call barring)
CC Setup
CC Call Proceeding
Translation of the Called Number

Assignment Command
Assignment Request
(CIC)
TCH
Assignment Complete
Release of
SDCCH Radio
Channel
Assignment Complete
139


MS
BSS
MSC/VLR
HLR/AuC/SCP/
V-MSC/VLR
MAP Send Routing Info.
Call
MAP Send Routing Info. Res
If Called Nb
= MSISDN
ISUP IAM
Setup
Phase
ISUP ACM
Called party
free & ringing
ISUP ANC
Called party
Answered
TCH
CC Alerting
CC Connect
CC Connect Ack.
Conv.
Phase
Call
Rel.
Phase
Conversation phase
CC Disconnect
CC Release
ISUP CLF
CC Release Complete
Release of Radio Resources
1 3 10
ISUP RLG

Steps of a Basic SS7 Call:

1) The caller takes the phone "off-hook", dial the destination number. The subscriber signaling pass this
information to the local calling office.
2) The local originating office which use SS7, encapsulates the dialed number and the CPC (calling Party
Category) information in to the first signal IAM (Initial Address Message) to setup the call to the destination
office. In some cases IAM can be replaced with IAI (Initial Address Message with Additional Information) to pass
more information.
3) On the route to the destination each receiving office checks the DPC (Destination Point Code) with its own
Point Code to see if the message is destined to itself. If not it transfers the message to the next office in the
route. When the destination office finally receives the IAM or IAI, it checks the subscriber number to see if it's
free. If free then sends back the ACM (Address Complete Message).
4) At this point, the voice circuit is opened, ring back tone is put on the circuit back to the caller and ringing
current is sent to the dialled number's phone.
5) When the called subscriber answers, the destination switching office sends back ANC (Address Charge
Message) to the first office to begin call charging.
6) When the conversation is over, to release the call circuit, the originating switching office sends CLF (Clear
Forward) and the destination switching office sends back the RLG (Release Guard) signals.

Call Setup phasing

Radio Link Establishment
SDCCH Phase
TCH assignment
Alerting/CNX Phase
4 steps for a call establishment
Each phase has a specific utility and some weaknesses

In the table, indicate which phases are used for each type of
connection:
CALL SETUP PHASES Signalling

Signalling
(LU,
CALL SETUP PHASES
IMSI
Det)
1 Radio Link Establisment
1
Radio
Link
Establisment
2 SDCCH Phase
2
Phase
3 SDCCH
TCH Assignment
SMS
SMS
3
Assignment
4 TCH
Alerting/Connection
4 Alerting/Connection
1 3 11


Call
GPRS Transfer
Call (OC/TC) GPRS Transfer
Paging
MS is "IMSI-attached" to the network: the MSC/VLR knows the L.A. in

which the MS is located.
BSC 1
MSC
ISUP
IAM
LAC 001
BSC 2
CS
PAG
LAC 002
PAGING
COMMAND
LAC 002
to each cell in the LAC 002
1 3 12

L.A.: Location Area (LAC: Location Area Code)

In the CS PAG (CS-Paging) message, the LAC that should be paged is included.

Successful Paging Procedure

MS3
MC925g x 3
MC930 x 1
Paging Request for Group 1
(MS1 , MS2)
Paging Request for Group 3
Connection
Setup
MC940
MC940
CS Paging (MS1)
MC940
CS Paging (MS3)
Multiple Paging Command
CS Paging (MS2)
MC8a
(MS1 pgr1, MS2 pgr1, MS3 pgr2)
MC925b
T3113
MC925b
(MS3)
Establishment Indication
incl. Paging Response
1 3 13
MC01
timer
stopped

Since B10, BSC can send Multiple Paging Command

MSC sends a PAGING message and starts the timer T3113 to supervise the PAGING RESPONSE message from the
MS. T3113 is started for each Paging !
The MSC may repeat the PAGING message if no answer arrives before T3113 expiry.
The BSC starts T_SEND_MULTIPLE_PAGING_CMD timer (assumed to be not yet running) when the first PAGING
message (MS1) is received.
When the number of PAGING messages queued in the BSC equals NB_MAX_MSG_MULTIPLE_PAGING_CMD, or at
T_SEND_MULTIPLE_PAGING_CMD expiry:
Multiple Paging Command is built and send to the cells.

Paging Discarded due to PCH Congestion

MS3
Paging Queue is full

Paging Command is
rejected
MC940
MC940
CS Paging (MS1)
MC940
CS Paging (MS3)
MC8a
(MS1 pgr1, MS2 pgr1, MS3 pgr2)
MC925h x 1
CS Paging (MS2)
T3113
timer
expires
CS Paging (MS3)
1 3 14


B11
Paging Coordination
For MS in Packet Transfer Mode, the BSC is able to forward the paging to the MFS !
EN_BSS_PAGING_COORDINATION = ENABLE
CS PAG
IMSI
Paging
PCH
1
Pa
TB
g
gin
BSC
SL
/R
g in
Pa
G
g/
CH
H
DC CH)
P
n AC
(+P
T
C
MSC
CS PAG / GSL
IMSI
HLR
SGSN
MFS
IMSI vs. MS Context
MS with a TBF is always owning 1 UL PACCH & 1 DL PACCH.

1 3 15

the BSC sends the paging either to the BTS or to the MFS, not both.

B11
Paging Coordination [cont.]
MS
BTS
BSC
MFS
MSC
PAGING (MS1)
T_SEND_MULTIPLE_PAGING_COMMAND
PAGING (MS2)
(50ms)
PAGING (MS3)
MC930
MC925g x3
Paging Req
(pgr 2, IMSI 1)
Paging Req
(pgr 8, IMSI 2 & 3)

(IMSI 1~3, pgr k)
OR
NB_MAX_MSG_MULTIPLE_PAGING_CMD
Paging Coordination Req
(IMSI 1~3)
P390a x 3
IMSI 3
not in PTM
Packet Paging Req (IMSI 1)
PACCH
GCH
PACCH
GCH
1 3 16
Packet Paging Req (IMSI 2)
GCH
GCH

To monitor GSL Load, use the following counters:

Type 7 L2.7 : TIME_GSL_LAPD_CONG
Type 110 MC960 : NB_DISCARDED_PS_CHAN_REQD_BECAUSE_GSL_CONGESTION
Type 110 MC1067 : AVG_NB_MSG_IN_GSL_QUEUE
etc.

P390b
P390b
(5)
Paging Request, Air Interface
Depending on how the MS is identified by the MSC, the Paging Request

is built by the BTS using a certain type:
Paging Request
Max. paged MS
Type 1
Type 2
Type 3
IMSI
or TMSI
or 2 x TMSI
or 2 x IMSI
or 1 TMSI + 1 IMSI
Possible combinations
3 x TMSI
4x TMSI
or 2 x TMSI + 1 IMSI
most common
1 3 17

In this table, TMSI can be replaced by P-TMSI (in case of PS Paging). A PS Paging can be merged with a CS Paging.

1 3 18


RLE Originated Call Success

SDCCH Phase
TCH assignment
Alerting/CNX Phase
MC925d
MC8c
MC148
MC925e
MC925a
IP21
only in case of IP BSS
MC8b
MC02
C255 Type 25 CR and CC messages

C254 Type 25
1 3 19
are exchanging the

references of the CIC

The SDCCH resource allocation is performed by the BSC. Once allocated, the SDCCH channel is activated by the BTS
on BSC request.
T3101 is the guard timer for the SDCCH access from the MS. The Default value is 3 seconds.
The SCCP Connection Request message is conveyed on an A interface PCM timeslot chosen by the BSC (called COC).
The SCCP Connection Confirm message is conveyed on a COC chosen by the MSC which can be located on a different
PCM than the one of the COC used by the BSC to send signaling messages to the MSC.
Originating + Destination Point Codes : N7 physical address
Originating + Destination References : Coc (call signalling) reference between MSC and BSC
Multiple SACCH Modify (New in B10) : request to send ASAP some system information messages that should be
updated when the MS moves from Idle Mode to Dedicated Mode (usually, the SI5, with the list of neighbours).

RLE Terminated Call Success

SDCCH Phase
TCH assignment
Alerting/CNX Phase
MC8a
MC925d
MC8c
MC148
MC925e
MC925a
IP21
only in case of IP BSS
MC8b
MC01
C255 Type 25
C254 Type 25
1 3 20

A paging message is broadcast by the MSC to all BSCs controlling cells belonging to the same Location Area as the one
of the paged MS.
In case no MS is accessing the SDCCH channel (T3101 expiry) then the BSC does not repeat the Immediate Assignment
since the MS may have accessed an SDCCH in another BSS. It is up to the MSC to repeat Paging if T3113 expires
(usually around 7 seconds).
MC8A counts the number of Paging Command messages sent on a cell.
MC01 counts the number of MSs which have successfully accessed an SDCCH in a cell as part of a Mobile Terminating
(MT) call.
CR: Complete L3 Info

RLE - Channel Request Message
Format of the message: 1 byte (8 bits)

8
Establishment Cause
Random Reference
Establishment Cause
Random Reference
Establishment Cause
Random Reference
Establishment Cause
Random Reference
1 3 21

NECI: New Establishment Cause Indication (0: not supported, 1: supported)

Answer to Paging:

RLE Call Distribution
Mobile Originating Cause Split: MC02

= MC02a+MC02b+MC02c+MC02d+MC02e+MC02f+MC02g+MC02h+MC02i
MC02A: Location Update & IMSI Attach
Could you find any other counters that
would give more details about SMS?
MC02B: SMS
MC02C: Supplementay Services
MC02D: Location Update with follow-on TCH
assignment for call establishment
MC02E: Call Reestablishment
C190 (Type 19) SMS Originated SDCCH

C191 (Type 19) SMS Terminated SDCCH
In NPO, in indicator family "SMS"
MC02F: L3 Info unknown by BSC but

forwarded to MSC
MC02G: IMSI Detach
MC02H: Normal or Emergency call
MC02i: Location Services (LCS)
1 3 22

Call Re-establishment (3GPP 24.008, 4.5.1.6)

The re-establishment takes place when a lower layer failure occurs and at least one MM connection is active (i.e..
the mobile station's MM sublayer is either in state 6 "MM CONNECTION ACTIVE" or state 20 "WAIT FOR ADDITIONAL
OUTGOING MM CONNECTION").
Supplementary services (SS) in GSM are a means of enriching the user experience. An SS may, for example, forward a
call in the case of no reply from the called party, bar certain outgoing or incoming calls, show the number of the
calling party to the called party, etc. The subscription to supplementary services is contained in the HLR and is sent
to the MSC/VLR during registration.
Name identification Calling name presentation (CNAP)
Call forwarding Call forwarding unconditional (CFU)
Call forwarding busy (CFB)
Call forwarding no reply (CFNRY)
Call forwarding not reachable (CFNRC)
etc.

RLE - SDCCH Congestion Failure
Main failure cases for Radio Link Establishment

SDCCH Assignment Unsuccess Rate
SDCCH Assignment Failure Congestion Rate
SDCCH Assignment Failure Radio Rate
SDCCH Assignment Failure BSS Rate
LapD Problem
This problem could impact any other phase as well
LAPD_Time_LAPD_Cong (L1.18, type 7)

LAPD_unavailable_time (L1.16, type 7)
1 3 23

The major errors during RLE are the following. Only some of them are described in this course.
1. SDCCH congestion: That is to say there are no SDCCH available in the cell.
2. Expiry of T9103: Caused by non reception of the CHANNEL ACTIVATION ACKNOWLEDGE or NEGATIVE ACKNOWLEDGE
during the channel activation procedure.
3. CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGE reception: During the channel activation procedure.
4. Expiry of T3101: Caused by the non reception of an ESTABLISH INDICATION with a layer 3 message during the
immediate assignment procedure.
5. Expiry of T9105: Caused by non reception of SCCP N-CONNECT CONFIRM or SCCP N-DISCONNECT INDICATION during
the SCCP connection establishment procedure.
6. Reception of SCCP N-DISCONNECT INDICATION during the SCCP connection establishment procedure: Caused by non
answer from MSC or reception of CREF during the SCCP connection establishment procedure.

BSC reaction depends on EN_IMM_ASS_REJ value

IF EN_IMM_ASS_REJ = DISABLE, no message is sent to MS
MS wait T3120 expiry and sends automatically another Channel Request
Up to MAX_RETRANS times (def = 2)
MC8c
T3120
MC04
(130ms)
1
MC8c
T3120
MC04
2
Time during which the

SDCCH are all busy in the
cell:
SDCCH_time_system_con
gestion = MC803
MC803
MC8c
T3126
MC04
MS goes back to IDLE MODE & displays "Network Error"

1 3 24

T3120 is computed by the MS as a random number of slots between:

* 250 and 250+T-1 for a phase 1 MS where:
T=Tx_integer parameter (1 value per cell chosen between 3 to 50 slots)
* S and T+S for a phase 2 MS where:
T=Tx_integer parameter (1 value per cell chosen between 3 to 50 slots, with 1 slot = 0.577ms)
S is a parameter depending on the CCCH configuration and on the value of Tx_integer as defined in the following
table:
TX_integer
S(CCCH Not Comb)
S(CCCH Combined)
3, 8, 14, 50
55
41
4, 9, 16
76
52
5, 10, 20
109
58
6, 11, 25
163
86
7, 12, 32
217
115
By default Tx_integer=32, then S=217. Therefore T3120 is between 125ms and 144ms.
T3126 is MS dependent, greater than T3120 but less than 5s.
After T3126 expiry, MS display "Network Error", except in case of LU, in which case the MS attempts to reselect
another cell and repeat the procedure. All Rights Reserved Alcatel-Lucent 2010
BSC reaction depends on EN_IMM_ASS_REJ value

IF EN_IMM_ASS_REJ = ENABLE, "Imm. Assg. Reject" is sent to MS
MS is forced to wait WI_xx before sending another Channel Request
Up to MAX_RETRANS times (def = 2)
MC8c
WI_OC
MC04
(=5s)
MC8c
WI_OC
MC04
2
Time during which the

SDCCH are all busy in the
cell:
SDCCH_time_system_con
gestion = MC803
MC803
MC8c
T3126
MC04
MS goes back to IDLE MODE & displays "Network Error"

1 3 25

WI_CR: Value of Wait Indication for Establishment cause = Call Re-establishment.

WI_DTM: Value of Wait Indication for DTM requests
WI_EC: Value of Wait Indication for Establishment cause = Emergency call.
WI_OC: Value of Wait Indication for Establishment cause = Originating call.
WI_OP: Value of Wait Indication for Establishment cause = Location updating or Other procedures which can be
completed with an SDCCH.
Wait indication used in IMMEDIATE ASSIGNMENT REJECT or PACKET ACCESS REJECT, when not in PMU CPU overload
situation.
Wait indication used in IMMEDIATE ASSIGNMENT REJECT or PACKET ACCESS REJECT, when in PMU CPU overload
situation.

RLE - SDCCH Cong. Impacts
In case of congestion, with default parameters:

For each "subscriber" call attempt, how many times the counter MC04 is
incremented ?
0
After MS finished its "n" automatic attempts, what is the next step ?
Displays "Network Error"
Automatic reselection + New call attempt
Subscriber should dial again

1 3 26

Subscriber attempt = when the subscriber presses the "Call" button

RLE - SDCCH Cong. Causes & Solutions
Location area border results in excessive location update and SDCCH

attempt
Inadequate LA design (too many LA's, or cell defined with wrong LAC value)
Modify CRH (Cell Reselect Hysteresis)
Increase T3212 (period location update)
Road is crossing LAC border Increase SDCCH capacity
Insufficient system capacity, lack of SDCCH channels

Could be caused by TRX failure
Add SDCCH channel
Enable dynamic SDCCH Dynamic Allocation function
Improper configuration of system parameters

TCH Queue is taking too long (while MS in queue, the SDCCH remains allocated)
Increase RACH_TA_FILTER with care!
1 3 27

SDCCH congestion can be too high because of the subscribers' traffic demand in terms of calls / LUs.
Solution = add a TRX or site / redesign the LA plan
High SDCCH congestion can be observed at peculiar period of the day due to a peak of LU requests generated by a big
group of subscribers entering a new LA at the same time (bus, train, plane).
Solution = redesign the LA plan or play on radio parameters (CELL_RESELECT_HYSTERESIS, WI_OP)
High SDCCH congestion can be abnormally observed without real MS traffic in case a high level of noise or the
proximity of a non-GSM radio transmitter.
Solution = change the BCCH frequency or put an RX filter
High SDCCH congestion can also be abnormally observed in a cell in case one of its neighboring cell is barred.
Solution = Remove the barring

RLE - SDCCH Cong. Causes & Solutions [cont.]
Abnormal SDCCH traffic

Neighboring cell barred
"Phantom" channel requests (explained in next slides)
Cha
EM
est
equ
R
l
nne
The Ghosts !
Real Subscribers
1 3 28
se
Noi


RLE Dynamic SDCCH
Some timeslots are configured as "SDD"

BSC configures the SDD as TCH, unless all static SDCCH are busy.
Particularly adapted to cells with peaks of LU or SMS.
MC8c
CHANNEL ACTIVATION
If no SDCCH currently free,

verify if SDD can be
reconfigured as SDCCH/8
If Successful, then
MC148
MC801a Avg TCH busy on a SDD
MC802a Avg SDCCH subchannels busy on a SDD
MC801b Max TCH busy on a SDD
MC802b Max SDCCH subchannels busy on a SDD
1 3 29

SDD possible in all TRX except first TRX if m-CCCH is enabled !

SPECIFIC COUNTERS (Type 110 / Cell Level):
MC800 Average number of available dynamic SDCCH/8 timeslots.
MC801
& MC802 counters are Inspection Counters; that means that the resource is checked regulary by the BSC and at the end of the
period, an average is done. Example: 3 physical channels are defined as Dyn SDCCH and the counter gives the following indication:
MC801a
= 1.7 that means sometimes the 3 Dyn SD are allocated as TCH, sometimes only 2 of them, sometimes 1 or 0 and the average is 1.7.
The FOLLOWING COUNTERS ARE IMPACTED BY the Dynamic SDCCH Allocation feature:
MC28, MC29 The Number of busy radio timeslots in TCH usage takes into account the busy TCH timeslots and the dynamic SDCCH/8
timeslots allocated as TCH.
C30, MC31 The Number of busy SDCCH sub-channels takes into account the SDCCH sub-channels allocated on the static and dynamic
SDCCH/8 timeslots.
C370a, MC370a, C370b, MC370b The Number of times the radio timeslots are allocated for TCH usage (FR / HR) takes into account the
busy TCH timeslots and the dynamic SDCCH/8 timeslots allocated as TCH.
C/MC380a/b C/MC381a/b The Cumulated time (in second) the radio timeslots are allocated for TCH usage (FR or HR) does not take care
whether the TCHs are allocated on the TCH radio timeslot or on the dynamic SDCCH/8 timeslots.
C39, MC390, C40, MC400 The Number of times or the Cumulated time (in second) the SDCCH sub-channels are busy does not take care
whether the SDCCH sub-channels are allocated on the static or dynamic SDCCH/x timeslot.
C/MC34 C/MC380 The Cumulated time (in second) all TCHs / SDCCHs in the cell are busy does not take care whether the TCHs / SDCCHs are
allocated on the TCH radio timeslot /SDCCH/x timeslot or on the dynamic SDCCH/8 timeslots.
C/MC320a/b/c/d/e Free TCH radio timeslots count the free TCH timeslots and the free dynamic SDCCH/8 timeslots.

RLE - SDCCH Radio Failure

Real problems
Ghost RACH
BSIC duplicates

MC8c
MC925d
MC148
IP21
MC8b
T3101 expiry !!
No Establishment Indication
1 3 30


MC149
RLE - Real SDCCH Radio Failures
Unbalanced cell power budget

Uplink is OK (Channel Request received)
Downlink is poor (BTS Tx is low, or MS Rx is poor)
Bad coverage (ex.: moving car) or Interference (DL or UL)

Radio link is unstable
Channel request could go through thanks to repetitions
In case of radio failure, the MS will retry as for SDCCH congestion
1 3 31

AGCH
Unbalanced Power Budget:
RACH
Max Path Loss DL

Max Path Loss UL
Channel Request
BTS
Bad coverage:
building
Access Grant
RACH
AGCH lost
Interference:
DL interference area
RLE - Ghost RACH
Synonyms: "Phantom/Ghost/Spurious/Dummy ... RACH"
Channel request received, but not sent by a MS. Why?
Electro-Magnetic Noise decoding within BTS

Reception of channel request sent to a neighboring cell
Reception of HO_ACCESS sent to a neighboring cell
MS has already performed a HO to another cell
MS has already reselected another cell
MS is already busy replying to its first channel request
Electro-Magnetic Noise from external interferer
Some tips to diagnose Ghost RACH:

1. Dummy Rach load depends on minimum level for decoding configured in BTS
2. During period with low real traffic (night), high rate of dummy RACH
3. For dummy RACH, the channel required has a random value of TA
1 3 32

Some of those reasons are "Real" ghost (= noise)

Others have a known and predictable cause

RLE - Ghost RACH Causes
Example of a channel required message from a real ghost RACH
1 3 33

For this Channel Required, the establishment cause is valid (Call re-establishment) but the Access Delay
(corresponding to the distance between the MS and the BTS) is high.
Indeed the Access Delay being equal to the Timing Advance is coded in slot unit representing a distance of 550m.
It can take values from 0 (0m) to 63 (35km).
Thus the Channel Required above is received from an MS located at 19km from the site. It may therefore be
rather a ghost RACH than a real MS which wants to re-establish a call.
In Alcatel-Lucent BSS, it is possible to filter the Channel Required received from a distance greater than a
distance defined as a parameter value: RACH_TA_FILTER tunable on a per-cell basis. Caution should be taken
since a too low value may reduce the network coverage.

RLE - Ghost RACH Causes [cont.]
If Abis over Satellite, round-trip time (RTT) is about 540ms

The MS autonomously repeats the Channel Request a second time
CHANNEL REQUEST (1)
CHANNEL REQUEST (2)
RTT
CHANNEL REQUIRED (1)

Ch. Act.
Ch. Act. Ack.
. (1)
IMM. ASSG
IMM. ASSIGNMENT (1)
. (2)
IMM. ASSG
In this scenario:
MC8c
=2
MC8b
=2
MC148
=2
MC02
=1
MC148
=1
Compute the value of SDCCH_assign_fail_radio_rate

= 1 / 2 = 50%
1 3 34

The CHANNEL REQUEST (2) is followed

by Channel
Required, Ch.inAct,
Ch SLOT"
Act Ack0 but they are not represented
STRUCTURE
of the MULTIFRAME
"TIME
here. Only the Immediate Assignment(2) is shown.
Round-Trip
Delay
(Non-combined
BCCH)
R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R -
UPLINK
(Multiframes of 51 frames)
1 2 3 4 5 6 7 8 9 10
20 21
31
41
51 1
f s b b b b C C C C f s C C C C C C C C f s C C C C C C C C f s C C C C C C C C f s C C C C C C C C - f s
f = FCCH
DOWNLINK
b = BCCH
s = SCH
C C C C = CCCH (PCH or AGCH)
R = RACH
(Combined BCCH)
DOWNLINK
FS
FS
F S
D0
D1
F S
D2
D3
FS
A0
A1
FS
FS
F S
D0
D1
F S
D2
D3
FS
A2
A3
UPLINK
D3
RR
A2
A3
RRRRRRRRRRRRRRRRRRRRRRR
D0
D1
RR
D2
D3
RR
A0
A1
RRRR RR RRRRR RRRRRRRRRRR R
D0
D1
RR
D2
F = FCCH S = SCH B = BCCH
C = CCCH (PCH or AGCH)
R = RACH
51 multiframe duration = 51 x 8 x 0,577 = 235ms

Dn/An = SDCCH/SACCH/4
RLE Same BCCH-BSIC couple (Channel Req.)
Subscriber not impacted (the real setup is performed elsewhere)

But MC149 incremented in far cell (SDCCH_assign_fail_radio_rate)
A simple radio planning rule is sufficient to avoid the trouble
"2 cells must not have the same BCCH/BSIC couple nearby"
include BSIC
Access burst (AB)
TB
8
Synchronization sequence
41
Encrypted bits
36
TB
3
GP
68,25
CHANNEL REQUEST (sent on BCCH frequency)
failure !
success !
cell 001
BCCH = 20
BSIC = 4/1
1 3 35

BSIC = BCC (3 bit) + NCC (3 bit)
BCC: BTS Color Code
NCC: Network Color Code

cell 019
BCCH = 20
BSIC = 4/1
RLE Same freq-BSIC couple (HO Access)
Same idea with worse impact

MS doesn't send one HO Access but four!
include BSIC
Access burst (AB)
TB
8
Synchronization sequence
41
Encrypted bits
36
TB
3
GP
68,25
4 x HO ACCESS (sent on target frequency 24)
failure !
success !
cell 001
TRX1 = 14
TRX2 = 24
TRX3 = 26
BSIC = 4/1
1 3 36

BSIC = BCC (3 bit) + NCC (3 bit)
BCC: BTS Color Code
NCC: Network Color Code

cell 019
TRX1 = 24
TRX2 = 28
TRX3 = 30
BSIC = 4/1
RLE Same freq-BSIC couple (HO Access) [cont.]
The BSC receives a CHANNEL REQUEST and a SDCCH sub-channel is

available. BSC allocates the SDCCH for that request.
For how long is this SDCCH subchannel reserved?

It is not reserved!
WI_xx
T3101 = 3 seconds (def.)
T3212
T9103
What is the impact on indicators of cell 019 ?

No impact
SDCCH_assign_req increases
SDCCH_assign_success decreases
SDCCH_assign_fail_radio_rate increases
SDCCH_assign_cong_rate increases
1 3 37


RLE - BSS Failure

This kind of failures cannot be counted: there is no trigger!

Knowing that:
SDCCH_assign_request = MC04 + MC148
SDCCH_assign_success = MC01 + MC02
What is the formula for SDCCH_assign_fail_BSS_rate?

attempt
radio fail
success
MC148 (MC149) (MC01 + MC02)

(MC04 + MC148)
request
1 3 38


RLE - Summary
REQUEST
GSM valid causes

ATTEMPT
invalid causes
Preparation Failure
Congestion
BSS problem
SUCCESS
Execution Failure
Execution
Radio access failure

BSS problem
1 3 39
Preparation
Request
MC8C
GSM invalid causes

GSM valid causes
unknown
unknown
Congestion
BSS Pb
MC04
unknown
Attempt
MC148
Radio Access Failure

BSS Pb
MC149
MC148 - (MC01+MC02) - MC149
Success
MC01+MC02


RLE - Indicators
In this graph, important informations are missing, which ones?

Congestion ! And the Unsuccess %
1 3 40

SDCCH_assign_cong
SDCCH_assign_fail_BSS
SDCCH_assign_fail_radio
SDCCH_assign_unsuccess_rate

Convention
Alcatel-Lucent always divides one procedure in 3 main steps:

KPI
Detailed
REQUEST
Preparation
Phase
ATTEMPT
SDCCH_assign
_cong_rate
Cong (BH, Max)

SDCCH_Load
Unavailability
Traffic Model
SDCCH_assign
_fail_rate
Radio Fail
BSS Fail
SDCCH_assign
_unsuccess_rate
Execution
Phase
SUCCESS
Fill up the table with indicators to monitor each phase
1 3 41


SDCCH Phase Originated Call Success
Once the SDCCH is allocated, it is used to pass "DTAP" messages

Exchange of signalling between MS and MSC
AUTHENTICATION REQUEST
IMSI check
AUTHENTICATION RESPONSE
CIPHER MODE Command
A5/x = ON
CIPHER MODE Complete

IDENTITY REQUEST
IMEI check
IDENTITY RESPONSE
AP
DT
es
ag
s
es
m
TMSI REALLOC Command

TMSI REALLOC Complete
TMSI changed
CALL SETUP
CALL PROCEEDING
1 3 42
other side = OK

DTAP : Direct Transfer Application Part, used for 3 purposes:

DTAP - RR: Radio Resources
DTAP - MM: Mobility Management
DTAP - CC: Call Control
http://www.acacia-net.com/wwwcla/protocol/gsma.htm

Paging of
called party
SDCCH Phase Terminated Call Success
Only the 2 last messages are changed
IMSI check
CIPHER MODE Command
A5/x = ON

IDENTITY REQUEST
IMEI check
IDENTITY RESPONSE
AP
DT
es
ag
s
es
m
TMSI REALLOC Command

TMSI changed
CALL SETUP
CALL CONFIRM
1 3 43
other side = OK

DTAP : Direct Transfer Application Part, used for 3 purposes:

DTAP - RR: Radio Resources
DTAP - MM: Mobility Management
DTAP - CC: Call Control
http://www.acacia-net.com/wwwcla/protocol/gsma.htm

CALL CONNECT
to calling party
SDCCH Phase Location Update Success
Goal: Update VLR with new LAC, and reallocate TMSI in MS
CLASSMARK ENQUIRY
CLASSMARK CHANGE
CLASSMARK ENQUIRY
CLASSMARK CHANGE
CLASSMARK Update
Optional
(BSS_SEND_CM_ENQUIRY)
Retrieve MS capabilities
IMSI check
CIPHER MODE Command
A5/x = ON

IDENTITY REQUEST
IMEI check
IDENTITY RESPONSE
AP
DT
es
ag
s
es
m
LOCATION UPDATE Accept

1 3 44
TMSI changed

BSS_SEND_CM_ENQUIRY
This flag is set by O&M to inform the BSC the conditions in which to send the CLASSMARK ENQUIRY message to the
MS.
The parameter has three defined values :
0 The CLASSMARK ENQUIRY is never initiated by the BSC
1 On reception of a LU REQUEST with ES IND flag is set to 0, the BSC will always initiate a CLASSMARK ENQUIRY.
2
On reception of a LU REQUEST with ES IND flag is set to 0, the BSC will initiate the CLASSMARK ENQUIRY only
if algorithm A5/1 is not available (information available in MS classmark 1 IE sent in the LOCATION UPDATING
REQUEST).
The MS classmark data is collected and stored by the Alcatel BSS and is used in almost all the procedures
performed by the Alcatel BS.
The MS classmark data collected by the BSS classmark handling entity is:
- the MS revision level,
- the MS ciphering capabilities which are supported by the BSS,
- the MS frequency capabilities which are supported by the BSS,
- the MS RF power capabilities in every frequency band supported by the MS and the BSS,
- the MS classmark handling capabilities
- the MS Utran classmark

SDCCH Phase - Drops
No dedicated counters for success case
In case of failure, the word to use is "drop"

It is a loss of connection during active transfer
3 causes of SDCCH drop:

Radio problems when connected on SDCCH
BSS problems
Call lost during an SDCCH HO (handover failure without reversion to old
channel)
SDCCH Drop Rate
SDCCH Drop Radio Rate
SDCCH Drop BSS Rate
SDCCH Drop HO Rate
1 3 45

Generally SDCCH handovers are disabled in the network since the average SDCCH duration is only around 2 to 3
seconds (parameter SDCCH_HO, with 0: SDCCH HO enabled, 1: SDCCH HO disabled)

SDCCH Phase - Radio Drop

SDCCH Drop Rate
SDCCH Drop BSS Rate
SDCCH Drop HO Rate
MS
BTS
BSC
SDCCH Phase established
MSC
Radio connection lost

---------------------------------------------------- > MC138
MC138
CONNECTION FAILURE INDICATION
(cause : radio link failure)
C180d --------------------------------------- >
CLEAR REQUEST
Cause : radio interface failure
1 3 46

MC138 counts the number of SDCCH channel drops due to radio problems.
Radio problems can be due to coverage, interference and sometimes BSS dysfunction which is not detected as a
system alarm by the O&M Fault Management application.
MC138 is triggered when either:
1/ RADIOLINK TIMEOUT reaches "0" in the BTS (generating a Connection Failure Indication "Radio link failure") Default
setting = 18 SACCH = 8.64s.
2/ or, LApD link failure, after (N200+1) * T200 seconds (24 * 220ms = 5.28s)

SDCCH Phase - BSS Drop

SDCCH Drop Rate
SDCCH Drop BSS Rate
SDCCH Drop HO Rate
MS
BTS
BSC
MSC
MC137
MC137
C180b --------------------------------------- >

or d CLEAR REQUEST
Cause : O&M intervention
Cause : radio interface failure
1 3 47

MC137 counts the number of SDCCH channel drops due to BSS problems.
A BSS problem can be a BTS/BSC hardware or software failure, or an O&M action on the DTC board. It can also be due
to a problem on the Abis interface (due to Micro Wave transmission for instance).
Triggers:
1) LapD failure detected during the stable phase of an SDCCH transaction.
2) SDCCH was released due to 48.058 ERROR REPORT with any cause value being received during the stable phase of
an SDCCH transaction (ciphering problems, or any other problem detected by the TRX).
3) Telecom Supervisory module caused the call to be cleared.
4) SDCCH was released due to 0180 CLEAR_CMD message being received from BSSAP during the stable phase of an
SDCCH transaction : O&M has disabled the DTC

SDCCH Phase - HO drop

SDCCH Drop Rate
SDCCH Drop BSS Rate
SDCCH Drop HO Rate
MS
BTS
BSC
HO FAILURE WITHOUT REVERSION
C180a
T3103 expiry !!
MC07
MSC
MC07
--------------------------------------- >
CLEAR REQUEST
Radio Interface Message Failure (Alcatel)
HO Failure & No Reversion to old channel Drop !

1 3 48

MC07 counts the number of SDCCH channel drops due to handover failure.
Internal inter-cell SDCCH handover: whenever the timer supervising the handover procedure (T3103) expires.

SDCCH Phase - Counters

SDCCH phase
Normal release
TCH assignment phase
SDCCH drop
What are the cases of "normal release"?
Drop radio
End of the Location Update, IMSI Detach,

SMS, SS procedures.
Drop BSS
SDCCH Phase
SDCCH connection
SDCCH Drop
MC01+MC02+MC10
Drop radio
Drop BSS
Drop HO
1 3 49
MC138
MC137
MC07


Drop HO
SDCCH Phase - Indicators
1 3 50

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:

GLOBAL Quality of service INDICATORS > SDCCH > Established phase
GSDCDR: SDCCH drop rate (Global)
GSDCDRR: SDCCH drop rate due to radio problem
GSDCDBR: SDCCH drop rate due to BSS Problem
GSDCDHR: SDCCH drop rate due to HO failure

SDCCH Phase - Exercise
With K1205 (file PAIB29.REC)

1) Extract a location update (successful case)
2) Extract a transaction with an SDCCH drop.
What is the cause of the failure?
Is it possible to "guess" the type of transaction (OC, TC, LU, etc.)?
3) Extract an SDCCH drop for a different cause.
Time allowed:
15 minutes
1 3 51


B11
TCH Assignment Success Case
MC140a
ASSIGNMENT REQUEST
PHYSICAL CONTEXT REQ.
stop
SDCCH
PHYSICAL CONTEXT CNF.

CHANNEL ACTIVATION
MC703
CHANNEL ACTIVATION ACK.

ASSIGNMENT COMMAND
Trr1
T9108
T9103
stop
MC140b
T3107
TCH
ATER CONNECT REQUEST

ATER CONNECT ACK.
SABM (FACCH)
ESTABLISH INDICATION
UA (FACCH)
RMS31 (*)
stop
ASSIGNMENT COMPLETE
(FACCH)
stop
MC718
1 3 52

RMS31: counted by the TRX, Whenever an ESTABLISH INDICATION message is received from the MS to indicate the
activation of a TCH channel for normal assignment or handover. Beware it is a RMS counter, it is measured
during the daily RMS campaign only.
B11 MR2: ATER CONNECT REQUEST / ACK in case of "IP BSS" and the call setup in a TDM BTS. The call will still be
carried by an AterMux nibble, rather than the IP backhaul.

TCH Assignment Phase Split
This is a reduced view of the message flow, showing only messages triggering counters.
Locate the preparation and the execution phase.
Link them to their indicators.
MC140a
ASSIGNMENT REQUEST
CHANNEL ACTIVATION
ASSIGNMENT COMMAND
MC703
MC140b
RTCH_assign_request = REQUEST
Preparation
Phase
RTCH_assign_command = ATTEMPT
Execution
Phase
ASSIGNMENT COMPLETE
(FACCH)
MC718
RTCH_assign_success = SUCCESS
Which indicator is linked to MC703?

RTCH_Assign_Allocated
1 3 53

Preparation phase: preparation of the resources, ends with a message SENT over the Air interface
Execution phase: validation that the new radio channel allows communication in both directions

B11
TCH Assignment MS Capabilities
Most MS
MS supports only FR
MC701a
MS supports only FR & DR
MC701b
MS supports EFR, FR & DR
MC701c
MS supports AMR FR & AMR HR
MC701d
Data calls
MC701e
MS supports only EFR & FR
MC701f
MS supports only EFR and/or HR
MC701g
MS supports AMR WB GMSK
MC932
MS supports A5/3 ciphering
MC951
ASSIGNMENT REQUEST
NPO
Next-gen MS
B11
Available in report
Alc_Mono_SpeechVersion_and_ChannelType
Thanks to those counters, it is possible to count how many MS can

support certain features
1 3 54

Next-Gen: Next Generation

B11
TCH Assignment - Congestion
MC140b
ASSIGNMENT REQUEST
no TCH available
in the cell
MC612a/b/c/d
ASSIGNMENT FAILURE
"No Radio Resource Available"
4 causes of congestion 4 counters. If no TCH available and
MC612 a.
Queue is disabled (by parameters) or not required by MSC

MC612 b. Queue is full (BTS_Q_LENGTH reached), or 9130 BSC's CCP is full
(MAX_TCH_PER_CCP is reached), or IP Abis is congested B11 MR2
MC612 c. Request stayed in the Queue too long (T11 or T11_FORCED expired)
MC612 d. Request is preempted by a high-priority request
RTCH_assign_cong = MC812 = MC612x
1 3 55


TCH Assignment Exercise
Using NPO or the Indicator Dictionary, propose indicators & methods to

start the investigation in a cell.
RTCH_assign_cong_rate = 15%
Check importance of problem thanks to:

RTCH_assign_cong_rate_BH & Hourly RTCH_assign_cong_rate
If real problem (not temporary peak), then 2 main possible problems
hardware problem?
too much traffic?
TCH availability
OMC-R Alarms
TCH traffic BH per TRX
TCH duration avg per TRX
TCH traffic BH per TRX

TCH traffic BH per cell
RTCH traffic load
Ratio of HR
Ratio of AMR HR
TCH Queuing indicators
Solutions:
Solutions:
Exchange TRX
Activate HR
Share load with other cells
Add TRX
Activate HR
Share load with other cells
1 3 56


TCH Assignment - Radio Failure in TCH Uplink
MC140a
ASSIGNMENT REQUEST
Trr1
SDCCH

CHANNEL ACTIVATION
SDCCH in DL still
probably OK
SDCCH
TCH
SABM (FACCH)
retransmitted up
to N200_LE times
MC703

ASSIGNMENT COMMAND
MC140b
T3107
x
x
SABM
UA
stop
ASSIGNMENT FAILURE
MC746b
ASSIGNMENT FAILURE
Radio interface failure
ASSIGNMENT REQUEST
1 3 57
expiry

MC746B counts the number of TCH access failures due to radio problems.
The MC746B counter is implemented at TRX level.
In case of TCH access failure, the MS will try to revert back to the SDCCH channel. Whether it succeeds in reverting
to the SDCCH or not the call establishment fails. On the other hand, some MSCs may resend the ASSIGNMENT
REQUEST again.

TCH Assignment - Radio Failure in TCH Downlink
MC140a
ASSIGNMENT REQUEST
Trr1
SDCCH

CHANNEL ACTIVATION
SDCCH in DL still
probably OK
SDCCH
TCH
SABM (FACCH)
SABM (FACCH)
x N200_LE
MC703

ASSIGNMENT COMMAND
MC140b
T3107
x
UA
UA
RMS31 (*)
SABM
UA
ASSIGNMENT FAILURE
stop
MC746b
ASSIGNMENT FAILURE
ASSIGNMENT REQUEST
1 3 58


expiry
TCH Assignment - Radio Failure at T3107 expiry
MC140a
ASSIGNMENT REQUEST
Trr1
SDCCH

CHANNEL ACTIVATION
SDCCH in DL still
probably OK
SDCCH
TCH
SABM (FACCH)
SABM (FACCH)
MC703

ASSIGNMENT COMMAND
MC140b
T3107
(14s)
x
x
x N200_LE
SABM
SABM
x
x
x N200_LE
expiry
MC746b
ASSIGNMENT FAILURE
ASSIGNMENT REQUEST
1 3 59


expiry
TCH Assignment - BSS Problem
No specific counter
Computed from the missing data
BSS Problems during preparation phase

= Requests Attempts Congestion Failures
= MC140a MC140b MC812
Probable cause: NSS or BSS software problems
BSS Problems during execution phase

= Attempts Success Radio Failures
= MC140b MC718 MC746b
Probable cause: Hardware problem, O&M intervention
1 3 60

"Probable cause" is just a possibility: It is not the only possible cause !

TCH Assignment - Counters
REQUEST
TCH assignment counters

ATTEMPT
SUCCESS
Preparation Failure
Execution Failure
Radio access failure
BSS problem
TCH Assignment
Preparation
Execution
Request
MC140a
Congestion
MC812
BSS Pb
MC140a-MC140b-MC812
Attempt
MC140b
Radio Access Failure
MC746b
BSS Pb
MC140b-MC718-MC746b
Success
MC718
1 3 61


Congestion
BSS problem
TCH Assignment - Indicators

TCH
Assignment indicators
1 3 62

Report: Alc_Mono_Call

TCH Assignment - Exercise
TCH assignment failure and BSC

1) Find and extract a case of TCH congestion (if any).
2) Find and extract a case of Assignment Failure due to Radio Problem (if any).
Time allowed:
15 minutes
1 3 63


1 3 64


Reminder
Global Indicators are

A set of indicators selected by Alcatel-Lucent
Useful to monitor the overall network
What are the user and or system impacts if a KPI is bad?
1 3 65


SDCCH Congestion Rate

Indicator
SDCCH ASSIGN
CONG FAIL RATE
Formulae
Threshold
(MC04) / SDCCH ASSIGN

REQUESTS
5%
Comments
Check SDCCH Erlang if not critical:
- SDCCH availability/allocation
problem,
- Or HO access on a nearby cell side
effect or interference on the carrier
handling SDCCH (the last 2 can lead
to high rate of phantom RACH )
Reference
name
Unit
GQSNACGR
SDCCH CONGESTION rate: may have low impact for subscriber

Failure impacting the user only after 3 subsequent congestion failures
Otherwise, only some extra delay for call establishment
Less than 1 second without immediate_assign_reject
Can be longer with immediate_assign_reject (but usually short values are used for
call request)
1 3 66

INDICATOR
DEFINITION
FORMULA
THRESHOLD
COMMENT
REF NAME
SDCCH ASSIGN REQUESTS

Number of SDCCH seizure requests during radio link establishment procedure
cell (MC148 + MC04)
This includes requests rejected due to congestion on SDCCH
SDNARQN
UNIT
(G) means that the indicator is GSM

Number
SDCCH Congestion Rate [cont.]

SDCCH
CONGESTION rate
SDCCH Assign Congestion - CELL2G: BA1046_1 (128/10461) ( 220/F05/128/10461

) - 02/03/2009 00 00:00 To 02/03/2009 23 23:00 (Working Zone: Global - Medium)
0.03%
5000
4500
0.02%
4000
3500
0.02%
Congestion
%
nb
3000
2500
2000
0.01%
1500
1000
0.01%
500
1 3 67


GLOBAL Quality of service INDICATORS > SDCCH > Assignment phase
GSDNACGR: SDCCH assignment failure rate due to congestion (Global)

23 23:00
22 22:00
21 21:00
20 20:00
19 19:00
18 18:00
17 17:00
16 16:00
15 15:00
14 14:00
13 13:00
12 12:00
11 11:00
10 10:00
09 09:00
08 08:00
07 07:00
06 06:00
05 05:00
04 04:00
03 03:00
02 02:00
01 01:00
0.00%
00 00:00
Request
% Congestion
SDCCH Failure Rate

Indicator
SDCCH ASSIGN
FAIL RATE
Formulae
Threshold
MC149 +
SDCCH_assign_fail_BSS /
5%
Comments
Check SDCCH Erlang if not critical:
- SDCCH availability/allocation
problem,
- Or HO access on a nearby cell side
effect or interference on the carrier
handling SDCCH (the last 2 can lead
to high rate of phantom RACH )
Reference
name
Unit
GSDNAFLR
SDCCH FAILURE rate: may have low impact for subscriber

Failure impacts the user only after 3 subsequent failures
In this indicator, only failure due to loss of radio link or failure due to "unknown"
causes are counted
Unknown causes are called "BSS", and generally happenbecause of hard- or soft-ware
failures
1 3 68

INDICATOR
DEFINITION
FORMULA
THRESHOLD
COMMENT
REF NAME

Number of SDCCH seizure requests during radio link establishment procedure
cell (MC148 + MC04)
This includes requests rejected due to congestion on SDCCH
SDNARQN
UNIT
(G) means that the indicator is GSM

Number
SDCCH Failure Rate [cont.]
SDCCH FAILURE rate

SDCCH assignment failure - CELL2G: BA1046_1 (128/10461) ( 220/F05/128/10461 ) 02/03/2009 00 00:00 To 02/03/2009 23 23:00 (Working Zone: Global - Medium)
5000
12.0%
4500
10.0%
4000
3500
8.0%
Fail - BSS
2500
6.0%
2000
4.0%
1500
1000
2.0%
500
1 3 69


GLOBAL Quality of service INDICATORS > SDCCH > Assignment phase

23 23:00
22 22:00
21 21:00
20 20:00
19 19:00
18 18:00
17 17:00
16 16:00
15 15:00
14 14:00
13 13:00
12 12:00
11 11:00
10 10:00
09 09:00
08 08:00
07 07:00
06 06:00
05 05:00
04 04:00
03 03:00
02 02:00
01 01:00
.0%
00 00:00
nb
3000
Fail - Radio
Success
% Fail
SDCCH Drop Rate

Indicator
SDCCH_drop_rate
Formulae
Threshold
(MC138 + MC07 + MC137) /

SDCCH ASSIGN SUCCESS
4%
Comments
Drop radio + Drop HO +
Drop BSS
Reference
name
Unit
GQSSDCDR
SDCCH DROP RATE
Rate of dropped SDCCH (SDCCH is established for any transaction OC, TC, LU,etc.)
1 3 70

INDICATOR
DEFINITION
FORMULA
THRESHOLD
COMMENT
REF NAME
SDCCH ASSIGN SUCCESS

Total number of SDCCHs successfully seized by mobile during radio link establishment
procedure
cell (MC01 + MC02)
SDNASUN
UNIT
Number
In a dense network, SDCCH drop rate should be lower than 1%. Indeed the probablity to drop a radio link when the
MS is on SDCCH is less than on TCH since the SDCCH phase is shorter (less than 5 seconds) than TCH phase
(duration of a call = several tens of seconds).

SDCCH Drop Rate [cont.]
SDCCH Drop Rate

SDCCH Drop - CELL2G: 02/03/2009 00 00:00 To 02/03/2009 23 23:00 (Working
Zone: Global - Medium)
60
2.5%
50
2.%
40
Drop - BSS
%
nb
1.5%
30
1.%
20
0.5%
10
1 3 71


23 23:00
22 22:00
21 21:00
20 20:00
19 19:00
18 18:00
17 17:00
16 16:00
15 15:00
14 14:00
13 13:00
12 12:00
11 11:00
10 10:00
09 09:00
08 08:00
07 07:00
06 06:00
05 05:00
04 04:00
03 03:00
02 02:00
01 01:00
0.%
00 00:00
Drop - HO
Drop - Radio
% Drop
TCH Assign Unsuccess Rate

Indicator
Formulae
TCH_assignment_
unsuccess_rate
Threshold
(TCH ASSIGN REQUESTS

TCH ASSIGN SUCCESS) /
TCH ASSIGN REQUESTS
Comments
Reference name
Unit
GQSTCNAUR
3%
TCH ASSIGN UNSUCCESS rate:
Rate of unsuccessful RTCH seizures for normal assignment purpose:
Congestion during Call Setup (not during Handover !!)

Radio problem
BSS problems
1 3 72

In a dense network, the TCH assignment unsuccess rate should be lower than 1%.
T C H A S S IG N R E Q U E S T S
IN D IC A T O R
D E F IN IT IO N
N u m b e r o f T C H s e iz u r e re q u e s ts fo r n o r m a l a s s ig n m e n t p r o c e d u re .
FO RM U LA B8
c e ll
M C 140a
TH R ESH O LD
CO M M ENT
M C 1 4 0 a : n e w c o u n te r in tr o d u c e d in B 8 re le a s e .
M C 1 4 0 a (ty p e 1 1 0 ) : N B _ T C H _ N O R _ A S S _ R E Q th a t in d ic a te s th e n u m b e r o f n o r m a l a s s ig n m e n t
re q u e s ts f o r T C H e s ta b lis h m e n t ( in H R o r F R u s a g e )
REF NAM E
TCNARQN
N um ber
TCH ASSIGN SUCCESS
INDICATOR
DEFINITION
FORM ULA B8
THRESHOLD
COM M ENT
REF NAM E
U N IT
Number of TCH successfully seized by MS for normal assignment procedure.

TRX (M C718)
TCNASUN
UNIT

Number
TCH Assign Unsuccess Rate Preparation Phase
TCH Assign Preparation

RTCH assign preparation - CELL2G: 02/03/2009 00 00:00 To 02/03/2009 23 23:00
(Working Zone: Global - Medium)
7.00%
1200
6.00%
1000
5.00%
800
4.00%
600
3.00%
400
2.00%
200
1.00%
0.00%
Prep Fail BSS

Congestion
1 3 73
22
:0
0
20
:0
0
22
20
18
:0
0
18
16
:0
0
16
14
:0
0
14
12
:0
0
12
10
:0
0
10
08
:0
0
08
06
:0
0
04
:0
0
06
04
02
:0
0
02
00
00
:0
0
nb
1400


Request
% Prep Fail BSS
% Congestion
TCH Assign Unsuccess Rate Execution Phase
TCH Assign Execution

RTCH assign execution - CELL2G: 02/03/2009 00 00:00 To 02/03/2009 23 23:00
(Working Zone: Global - Medium)
1200
2.5%
1000
2.%
Exe Fail BSS
800
Fail Radio
%
600
1.%
400
Success
% Exe Fail BSS
% Fail Radio
0.5%
200
1 3 74
22
:0
0
22
20
:0
0
20
18
:0
0
18
16
:0
0
16
14
:0
0
14
12
12
:0
0
10
:0
0
10
08
:0
0
08
06
:0
0
06
04
:0
0
04
02
02
:0
0
0.%
00
:0
0
00
nb
1.5%


Cell Congestion Rate

Indicator
Formulae
RTCH_Assign_Cong_Rate
Thres
hold
Comments
Reference name
3%
Normal Assignment
GTCNACGR
Incoming HO
GTCHOCGR
RTCH_assign_cong / RTCH_assign_request
Used in "TCH Assign Unsuccess Rate" calculation

RTCH_HO_Cong_Rate
RTCH_HO_cong / RTCH_HO_request
3%
(TCH intra & intercell)

RTCH_cong_rate
Call_cong_rate
(RTCH_assign_cong + RTCH_HO_cong) /
(RTCH_assign_request + RTCH_HO_request)
3%
(RTCH_assign_cong + HO_Inc_cong) /
(RTCH_assign_request + RTCH_HO_allocated
+ HO_Inc_cong)
3%
NA + Inc HO
GTCAHCGR
(TCH intra & intercell)

Inc HO takes into
account SDCCH & TCH
intercell HO
GQSCGR
4 Different Indicators: Which one is the KPI?

Subscriber is directly impacted by TCH NA Congestion, but not by HO Congestion
Indeed, a HO congestion leads to another HO attempt, not to a call failure

Therefore, RTCH_Assign_Cong_Rate is the best image of "end user"-congestion
1 3 75

This counter intends to give a measurement of the TCH congestion of the whole network.
It is implemented on the Alcatel-Lucent tools but other indicators can be defined.
RTCH_assign_cong
new:MC812, old:MC812
HO_Inc_cong = HO_Inc_MSC_cong + HO_Inc_BSC_cong

RTCH_assign_request = new:MC140a-(MC142e+MC142f), old:MC140a-(MC142e+MC142f)
RTCH_HO_allocated = new:MC15b + MC15a, old:MC15b + MC15a
HO_Inc_cong = HO_Inc_MSC_cong + HO_Inc_BSC_cong
Note: The congestion counted in those indicators is linked to the following issues:
1) all TCH are busy and no TCH could be allocated for the request
2) or the CCP board in the MX-BSC reaches the limit MAX_TCH_PER_CCP (default = 1000)
MC926 : Number of TCH channel allocation rejected for cause : Maximum TCH processing capacity of CCP reached
Whenever a TCH cannot be allocated due to the TCH processing capacity of CCP reaches the limit defined by the
MAX_TCH_PER_CCP parameter.

Call Setup Success Rate

MS
BTS
BSC
MSC
SDCCH assignment success
ESTAB IND (CM_Serv_Req)
SCCP CON REQ (CM_Serv_Req)

SCCP CON CONFIRM
Authentification Procedure
SDCCH Drop
incl. Call, SMS, LU
IMSI Detach, etc
Identification Procedure
Ciphering Procedure
SETUP
CALL PROCEEDING
ASSIGNMENT REQUEST
Assignment Procedure
ASSIGNMENT COMPLETE
TCH Assign
Unsuccess
(for normal
assignment only)
ALERTING
CONNECT
Normal assignment success
CONNECT ACK.
1 3 76

will always be smaller than the GQSCSSR, because all failures due to NSS are now taking into account. They
were not counted in the CSSR.
GQSEECSSR

Call Setup Success Rate [cont.]

Indicator
Call_setup_success
_rate
Threshol
d
Formulae
(1 SDCCH DROP RATE) * (1 - TCH

ASSIGN UNSUCCESS RATE)
95%
Comments
SDCCH assignment
unsuccesses are not
considered in CSSR as :
Reference
name
Unit
GQSCSSR
ghost (spurious) RACH

cannot be discriminated
from a real access failure
effect of re-attempts
performed autonomously by
the MS cannot be quantified
CALL SETUP SUCCESS rate: Rate of calls going until TCH successful assignment, that is not
interrupted by SDCCH DROP neither by Assignment failures
The second most important indicator
Used to compare PLMN
Subscriber: call not established at the first attempt
Beware: call setup failures due to a lack of coverage are not taken into account in this indicator!!
No way to quantify them (as there is no initial access)
1 3 77

Ghost Racks which correspond to a valid establishment cause are not identified by the BSS. Therefore they can lead
to a high SDCCH assignment failure rate if they are too numerous.
As the end user is not impacted by this phenomenon if no SDCCH congestion is induced, the SDCCH assignment phase
is not considered in the computation of the Call Setup Success rate provided by Alcatel-Lucent tools.
In a dense network, the Call Setup Success Rate should be greater than 98%.
The SDCCH congestion rate should also be considered to have a complete picture of Call Setup efficiency.

Call Success Rate
Indicator
Call_success_rate
Formulae
(CALL SETUP SUCCESS RATE)

* (1 CALL DROP RATE)
Thresho
ld
Comments
92%
Reference
name
Unit
GQSCCR
CALL SUCCESS rate: Rate of calls going until normal release , that is not interrupted
by SDCCH DROP, neither by Assignment Failures nor by CALL DROP
1 call success =
1 call successfully established
Without any call drop
1 3 78

In a dense network, the Call Setup Success Rate should be greater than 97%.

End to End Call Setup Success Rate

MS
BTS
BSC
ESTAB IND (CM_Serv_Req)
MSC
SDCCH assignment success
SCCP CON REQ (CM_Serv_Req)
SCCP CON CONFIRM
Authentification Procedure
Identification Procedure
Ciphering Procedure
E2E CSSR
SETUP
CALL PROCEEDING
ASSIGNMENT REQUEST
Assignment Procedure
ASSIGNMENT COMPLETE
ALERTING
Normal assignment success
CONNECT
CONNECT ACK.
1 3 79

will always be smaller than the GQSCSSR, because all failures due to NSS are now taking into account. They
were not counted in the CSSR.
GQSEECSSR

End to End Call Setup Success Rate [cont.]
Indicator
Formulae
Threshold
End_to_End_call_setup (RTCH_assign_success + DR_Out_internal_success +

DR_Out_external_success)
_success_rate
91%
Reference
Unit
name
GQSEECSSR
/ (MT_SDCCH_assign_success - SDCCH_SMS_MT_PP_connection+
SDCCH_traffic_Call_reestab + SDCCH_traffic_lu_for +
SDCCH_traffic_other_mo + SDCCH_traffic_moc)
MC 718 MC142e MC142 f

MC 01 MC191 MC 02e MC 02d MC 02 f MC 02h
End to End CSSR : The successes of call setup phase (between the SDCCH assignment success and the
TCH assignment success) taking into account all what can happen during this phase between MS and
MSC
View of the call setup success rate from the end user point-of-view.
Have a global view of the end-user perceived quality of their GSM network, whatever the problems
encountered. Fastest detection and correction of problems would be possible, leading to improved
quality.
1 3 80

MC718 : Number of TCH (in HR or FR usage) normal assignment successes, per TRX (ASSIGNMENT COMPLETE).
MC142e : Number of outgoing normal & forced internal directed retry (towards a TCH channel in HR or FR usage)
successes.
MC142f : Number of outgoing normal & forced external directed retry (towards a TCH channel in HR or FR usage)
successes.
MC01 : Number of immediate assignment plus SDCCH normal assignment successes for Mobile Terminating procedure
(ESTABLISH INDICATION w/ PAGING RESPONSE)
MC191 : Number of Mobile Terminating SMS connections on SDCCH.
MC02e : ESTABLISH INDICATION w/ CM RE-ESTABLISHMENT REQUEST
MC02d : ESTABLISH INDICATION w/ LOCATION UPDATING REQUEST with FORWARDING
MC02f : ESTABLISH INDICATION w/ unknown causes but forwarded to MSC (= leading to TCH establishment)
MC02h : ESTABLISH INDICATION w/ CM SERVICE REQUEST Normal Call or Emergency Call

Alc_Mono_Call
CALL SETUP SUCCESS RATE

CALL SUCCESS RATE
END TO END CALL SETUP SUCCESS RATE
1 3 81


GLOBAL Quality of service INDICATORS > Call statistics > Call success
GQSCSSR: Call setup success rate (Global)
GQSCCR: Call success rate (Global)
GQSEECSSR: End to End Call Setup Success Rate (Global)

Differences between CSSR and E2ECSSR
The main reasons for differences are:
1.
The MSC doesn't send the ASSIGNMENT REQUEST after CALL

PROCEEDING
Not impacted
Legacy CSSR
Degraded
E2E CSSR
2.
SDCCH Drops mostly during Location Updates & SMS & IMSI Detach
Not impacted
Degraded
Legacy CSSR
E2E CSSR
1 3 82



for this module
1 3 83


End of Module
Call Establishment
1 3 84


Section 1
Module 4
Communication Phase
GSM B11

Blank Page
142
B11 GSM QoS Monitoring Communication Phase

Document History
Edition
Date
Author
Remarks
01
2009-June
DIALLO
B11 features
02
2009-July
POURTAUBORDE
Changes in chapters structure, new exercises

Module Objectives
Explain call drops
Explain different kind of call drops
Understand call drop with special radio cause
143


144


Table of Contents
1 DTAP Establishment Phase
TCH Phase Success
TCH Phase TCH drop vs. DTAP drop
2 Call Release
Overview
Normal Release initiated by MSC
"Drop" Release initiated by BSC
3 Call Drop Causes
Radio Drop
Radio Drop: Radio Link TimeOut
Radio Drop: RLT with Repeated UL & DL SACCH
Radio Drop: RLT with Repeated DL FACCH
New Counters: RDFACCH & RSACCH
Remote TC Drop
BSS Internal Drop
Handover Drop
Preemption Drop
Summary of Counters
Definition
Causes of CDR
4 Which KPI?
Different Possibilities
Call
Drop Rate
145
RTCH
B11 GSM QoS Drop
Monitoring Rate
Communication Phase
TRX RTCH Drop (*) Rate
Choice of "Cell Level" KPI
Choice of "High Level" KPI
Alc_Mono_Call "CDR"
Call Drop - Exercise
5 Call Drop with Specific Radio Causes
Generalities
Thresholds for Detection
Counters
Indicators
Alc Mono Drop Causes
6 Summary of Call Setup and Call Phases
BSS and User point of view
Summary
List of KPIs for Management
List of KPIs for Monitoring
7 Traps and Restrictions of Indicators
Objective
CSSR & CDR
Call Duration
Mobility
Exercise
8 Indicators Interpretation
Exercise 1
Exercise 2
Exercise 2
Exercise
End of Module

Page
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

146


147


TCH Phase Success
Called party is
ringing
CONNECT
Called party
picked up
TCH
OC
ALERTING
CONNECT ACK
call ongoing
Billing starts
TC
TCH
ALERTING
CONNECT
CONNECT ACK
148
call ongoing

These messages are "DTAP" messages, transparent for the BSC and the BTS, and are carried over FACCH.
Alerting time can last a very long time, it is not neglictible !!

TCH Phase TCH drop vs. DTAP drop

Where does the call start ?
For BSS
For NSS
ALERTING
CONNECT
CONNECT ACK
call ongoing
For BSS, call drop can occur as

soon as RTCH is used
Call ongoing
OC
RTCH ongoing
TCH
ASSIGN COMPLETE
For NSS, call drop is counted

only after CONNECT ACK =
DTAP Established Phase
149

For NSS, before the CONNECT ACK is still considered as a CALL SETUP FAILURE.
MS
BTS
BSC
M SC
TCH ASSIGNMENT PHASE (O C or TC)
< ----------------------------------ASSIGNM ENT REQ UEST
< -------------------------------------------------------PHYSICAL CO NTEXT REQUEST
-------------------------------------------------------- >
PHYSICAL CO NT EXT CONFIRM
< -------------------------------------------------------CHANNEL ACT IVATIO N (TCH)
-------------------------------------------------------- >
CHANNEL ACTIVATIO N ACKNO W LEDG E
Call Setup
< ----------------------------------------------------------------------------------(SDCCH)
ASSIG NM ENT CO M M AND
TCH
---------------------- >
SABM
< ---------------------UA
Call Setup
Start T3107
-------------------------------------------------------- >
ESTABLISH INDICATIO N
----------------------------------------------------------------------------------- >
ASSIG NM ENT CO M PLETE
Stop T3107
----------------------------------- >
ASSIG NM ENT CO M PLETE
Call phase
< --------------------------------------------------------------------------------------------------------------------------ALERTING
< --------------------------------------------------------------------------------------------------------------------------CO NNECT
---------------------------------------------------------------------------------------------------------------------------->
CO NNECT ACK
Call phase

2 Call Release
1 4 10


2 Call Release
Overview
Call release in a cell = Release of the radio timeslot TCH

Call release for end user = Communication with other party is finished
From cell point of view, TCH is released in 3 different cases:
End of call
(Normal Release)
1 4 11
Outgoing Handover
Internal or External
Call Drops
Detailed in HO chapter
Main topic of this chapter


2 Call Release
Normal Release initiated by MSC
The MSC's normal method of releasing a connection at the end of a call,

LU, IMSI Detach or SMS connection (etc.)
1 4 12

(1) The MSC initiates the release by sending the CLEAR COMMAND.
(2) The BSC releases any A Channel resources, requests the TC to release Atermux nibble-TIC connection (if there
is such a connection), switches off the traffic path in the BSC and returns immediately the CLEAR COMPLETE
message to the MSC. Note that the BSC will accept any CLEAR COMMAND message even if the MIE is not present
or the cause is unknown.
In the case where there is a channel change procedure in progress, the whereabouts of the MS is awaited before
the release is initiated on Radio and A-bis.
The MSC upon reception of the CLEAR COMPLETE releases any A Channel resources associated to the connection
and should initiate the release of the SCCP resource.
(3) The BSC starts the timer T9101 to supervise the release of the SCCP resource.
(4) The MSC releases the SCCP resource by sending the SCCP RELEASED message to the BSC. The BSC stops T9101
and returns the SCCP RELEASE COMPLETE message and the SCCP resources are now considered released.

2 Call Release
"Drop" Release initiated by BSC
BSC's normal method of a connection release due to drops
Type 18: C180x
1 4 13

(1) The BSC detects an event, and signals the requirement to release the connection by sending the CLEAR
REQUEST to the MSC, and starts the timer T9104 to supervise the procedure.
(2) The MSC responds by sending a CLEAR COMMAND. The BSC stops the timer T9104, if the MS is still connected
the BSC will initiate a call release scenario towards the MS and then release the resources in the BTS.
(3) The BSC releases any associated A channel, Atermux nibble-TIC connection and any associated traffic path,
and sends the CLEAR COMPLETE. The release of the SCCP connection is awaited. The timer T9101 is started to
guard the release of the SCCP
connection by the MSC.
(4) The MSC, on reception of the CLEAR COMPLETE, should release any associated A channel resource and release
the SCCP connection by sending the SCCP RELEASED message to the BSC. The BSC should respond with the
SCCP RELEASE COMPLETE and stop T9101.

3 Call Drop Causes
1 4 14


3 Call Drop Causes
TCH
Radio Drop
Meas. Report
Meas. Report
Meas. Report
x
x
x
CONNECT FAILURE
INDICATION
radio link failure
C180d
MC736
CLEAR REQUEST
radio interface failure
The BTS detects the radio link failure

Mechanism based on several consecutive UL SACCH frames not
decoded (Radiolink Timeout)
1 4 15

MC736 counts the number of TCH channel drops due to radio problems for non AMR calls. Similar counters exist for
AMR calls (cf next slides)
The MC736 counter is implemented at TRX level.
Radio problems can be due to coverage, interference and sometimes BSS dysfunction which is not detected as a
system alarm by the O&M Fault Management application.

B11
3 Call Drop Causes
Radio Drop: Radio Link TimeOut
For each active radio channel, a counter S is

decremented by 1 each time an SACCH frame cannot be decoded (BFI=1)
incremented by 2 each time a valid SACCH frame is received
Initial value of S = RADIO_LINK_TIMEOUT_BS for non-AMR calls or AMR calls with

RSACCH + RDFACCH B11
if S reaches N_BSTXPWR_M, a radio link recovery is triggered (optional)
if S reaches 0, a radio link failure is detected
New Radio link Timeout parameters has been introduced for AMR calls without RxACCH
RADIO_LINK_TIMEOUT_BS_AMR
RADIO_LINK_TIMEOUT_AMR
B11
RLS Counter
When S=0, RADIO CALL DROP !!!

RADIOLINK_TIMEOUT_BS
BTS
17
16
15
14
13
12
11
10
09
Rel-6 MS
1 4 16
RADIOLINK_RECOVERY_THRES
(PC)
Bad
UL SACCH

RADIOLINK_TIMEOUT_BS RADIOLINK_TIMEOUT is important because the mobile must release the radio channel
first. If BTS releases the TCH, then it can be reallocated to another MS.
Use RADIOLINK_TIMEOUT_BS_AMR instead of RADIOLINK_TIMEOUT_BS if:
AMR (NB or WB) codec is used
AND
( RSACCH is not activated by the BSC for this call
OR
RDFACCH is not activated by the BSC for LAPDM command frames of this call )

B11
3 Call Drop Causes
Radio Drop: RLT with Repeated UL & DL SACCH
Acronym: RSACCH
Target: AMR calls from Rel-6 onwards MS
Goal: Extend coverage & reduce number of call drops, for MS Rel-6 onwards only.
The RDSACCH mechanism means that the BSS may send a DL SACCH frame twice with exactly
the same contents to improve the DL SACCH performance thanks to combining in the MS.
The RUSACCH mechanism means that an MS shall send upon BSS order a UL SACCH frame twice
with exactly the same contents to improve the UL SACCH performance thanks to combining in
the BTS.
RLS Counter
RADIOLINK_TIMEOUT_BS
BTS
17
16
15
14
13
12
11
10
RADIOLINK_RECOVERY_THRES
(PC)
RADIOLINK_REP_DL_SACCH
(Repeated SACCH activation)
09
Rel-6 MS
1 4 17
Bad
UL SACCH

When a SACCH block is received:

- If EN_REP_SACCH=0: If the SACCH block can be decoded, then S is incremented by 2,
Else S is decremented by 1.
- If EN_REP_SACCH=1: If the SACCH block can be decoded, then S is incremented by 2,
Else If the second attempt to decode it after combining with the previous SACCH block, then then S is
incremented by 2,
Else S is decremented by 1.
NB: the BTS does not know whether an UL SACCH frame is a repetition or not.

B11
3 Call Drop Causes
Radio Drop: RLT with Repeated DL FACCH
Acronym: RDFACCH
Target: AMR calls from Rel-6 onwards MS
Goal: Improve HO reliability for AMR calls
H fr
am e
When the RDFACCH feature is enabled, each DL FACCH frame is sent twice with exactly the same
contents
If there was an unsuccessfully decoded FACCH block, a new decoding using these 2 FACCH blocks
shall be performed thanks to soft combining.
BTS
LAPDm
Rel-6 MS during
AMR call
FACCH c,2
17
16
15
14
13
12
11
10
TCH frame
FACCH c,1
TCH frame
TCH frame
FACCH b,2
TCH frame
FACCH b,1
TCH frame
TCH frame
TCH frame
FACCH a,2
TCH frame
FACCH a,1
TCH frame
TCH
09
Soft combining
1 4 18

Support of RDFACCH is mandatory for Rel-6 mobile stations.

f ra m
Downlink
Outcome of
the decoding
process
B11
3 Call Drop Causes
New Counters: RDFACCH & RSACCH

Short
Name
Definition
"Number of "
Name
Object
MC990
NB_MS_REPEATED_ACCH_CAPABLE
Calls for which the MS supports the

repeated ACCH capability
TRX
MC991
NB_CALLS_RFACCH_ACTIVATED
Calls for which Repeated FACCH is

activated
TRX
MC992
NB_CALLS_RSACCH_ACTIVATED
Calls for which Repeated SACCH is

activated (UL or DL)
TRX
MC993
NB_AMR_TCH_DROP_RLF_TRX
AMR TCH dropped due to radio link failure,

for which Repeated SACCH is not activated
TRX
MC994
NB_AMR_TCH_DROP_RLF_TRX_RSACCH
AMR TCH dropped due to radio link failure,

for which Repeated SACCH is activated
TRX
MC995
NB_AMR_TCH_DROP_OUT_HO_TRX
AMR TCH dropped during outgoing HO

17
execution, for 16
which Repeated SACCH is
not activated 15
TRX
MC996
14
AMR TCH dropped
during outgoing HO
13
NB_AMR_TCH_DROP_OUT_HO_TRX_RFACCH execution, for 12
which Repeated SACCH is
not activated 11
TRX
10
09
1 4 19


3 Call Drop Causes
Remote TC Drop
TC
TCH
DL TRAU with UFE

CONNECT FAILURE INDICATION
remote transcoder failure
MC739
C180c
CLEAR REQUEST
equipment failure
BTS initiates call release due to BTS-TC connection problem:

Loss of TRAU synchronization is done by the TC (in UL) or by the TRX (in DL)
(example above: detection by TC)
Cause:
Hardware failure along the TRAU path but where ?
BTS
BSC
TC
UL TRAU
ANC
TRE
SUM
Abis
TCU
DTC
Ater
TCIF
MT120
DL TRAU
1 4 20

MC739 counts the number of TCH channel drops due to BSS problems reported as "remote TransCoder failure".
The MC739 counter is implemented at TRX level.
It can usually be a bad quality of the transmission on the Abis interface (Micro Wave) or a faulty hardware component
in the TransCoder or even sometimes BSS software/hardware problems.
UFE: Uplink Frame Error is a field in the TRAU frame indicating a loss of synchro.
T_SYNC: Timer used in the BTS to detect a loss of synchronisation between BTS and transcoder (default: 1s)
A loss of frame synchronisation is assumed as soon as a single TRAU frame with a frame synchronisation error is
received.

3 Call Drop Causes
BSS Internal Drop
TCH
O&M action
C180b
MC14c
CLEAR REQUEST
O&M intervention
Causes:
O&M intervention (TRX Reset, etc.)
Software failures not affecting TRAU synchronization
RSL Abis timeslot failure (but TCH Abis timeslot is OK) (very rare)
1 4 21


3 Call Drop Causes
Handover Drop
TCH
T3103
non-AMR
MC621
all
MC714
C180a
HO FAILURE
without REVERSION
expiry
CLEAR REQUEST
"Radio Interface
Message Failure"
MC621
Number of non-AMR TCH drops during the execution of any TCH outgoing handover. Includes intra &
inter PLMN and 2G-3G HO.
MC714
Nb of outgoing TCH handover execution failures due to MS access problem without reversion of the
mobile to the old channel (call drop). Includes intra & inter PLMN and 2G-3G HO.
1 4 22

Note: in B11 MR2, the CALL DROP HO formula is modified = MC621+MC995+MC996, instead of = MC621
This event is also counted in the set of Handover counters as an Outgoing handover failure without reversion to the
old channel.
HO is "failed" and leads to a call drop :
1) Inter-cell TCH handover: whenever the timer supervising the handover procedure (T3103) expires.
2) External TCH handover (2G -> 2G): whenever the timer supervising the handover procedure on the serving cell (T8)
expires
3) Intra-cell TCH handover: whenever the timer supervising the handover procedure (T3107) expires.
4) 2G -> 3G HO: whenever the timer supervising the 2G-3G handover procedure on the serving cell (T3121) expires

3 Call Drop Causes
Preemption Drop
In this cell, no more free TCH, and 1 MS in TCH phase with pvi = 0 and priority = pl2
Another MS starts a call. In HLR, this MS has priority level = pl1 (> pl2) and pci = 1
TCH
MC921b
MC921c
1 4 23
ASSIGNMENT REQUEST
from "hi prio" MS
pci = 1
CLEAR REQUEST
"Preemption"

MC921C counts the number of TCH channel drops due to preemption for another call to be established.
The MC921C counter exists from B7 as linked to the feature Preemption.

3 Call Drop Causes
Summary of Counters
TYPICAL CALL FAILURES: TCH phase counters

TCH connection
NSS abnormal release
Normal release
Outgoing HO success
Call drop
TCH Phase
TCH connection
MC718+MC717A+MC717B
Outgoing HO success
MC712
Call drop
Drop
Drop
Drop
Drop
Drop
radio
TC
internal BSS
HO
preemption
Normal release
NSS abnormal release
1 4 24
MC736
MC739
MC14C
MC621 +MC995+MC996
MC921C
unknown
unknown


Call drop preemption
Call drop radio

Remote TC
Call drop BSS

BSS internal
Call drop HO
3 Call Drop Causes
Definition
Indicator
Formulae
Call_drop_rate
Call_drop / RTCH_success_end
Threshold
Unit
4%
The most important indicator

Used with call setup success rate to compare PLMN
Subscriber impact : call drop !!
1 4 25

RTCH_success_end: RTCH_success - RTCH_HO_Out_success

B11
3 Call Drop Causes
Causes of CDR
Indicators
Call_drop_radio_rate
Formulae
MC736+MC993+MC994 / RTCH_success_end
Threshold
Unit
%
B11
Call_drop_HO_rate
MC621 + MC995 + MC996 / RTCH_success_end
B11
Call_drop_remote_TC_rate
MC739 / RTCH_success_end
Call_drop_BSS_int_failure_rate
MC14c / RTCH_success_end
Call_drop_preemption_rate
MC921c / RTCH_success_end
1 4 26

In B11, the global formulaes of radio and HO drops have changed, but in the end, they are sill counting the same
thing than before.
MC736 : NB_TCH_DROP_EST_PHAS_RLF_TRX (non AMR calls)
MC621 : NB_TCH_DROP_OUT_HO_EXEC_TRX
MC739 : NB_TCH_DROP_EST_PHAS_REM_TRANS_FAIL_TRX
MC14c : NB_TCH_DROP_EST_PHAS_BSS_PB
MC921c : NB_PREEMPTED_CALLS

4 Which KPI?
1 4 27


4 Which KPI?
Different Possibilities
There are different "drop rates" available:

Based on number of drops during the whole RTCH phase, for calls
Call Drop Rate
RTCH Drop Rate
TRX RTCH Drop (radio / rtc / ho) Rate
Based on number of CLEAR REQUESTS during calls or handovers (SS7 view)

A Call Drop Rate
A RTCH Drop Rate
Based on number of drops during the DTAP established phase only

Call Drop End User Rate
1 4 28


4 Which KPI?
Call Drop Rate
Call drop rate (CDR) = Call drop / RTCH success end

100 inc HO
cell n1
100 N.A.
150 out HO
10 Drops
cell n2
cell S
RTCH success end = rtch assignment success + rtch incoming (HO+DR) success
- rtch outgoing HO success
CDR = 10 / (100 + 100 150) = 20%
1 4 29

GQSCDN = call drop

= drop radio + drop TC + drop internal BSS + drop HO + drop Preemption
= MC736 + MC739 + MC14C + MC621 + MC921C
GTCQHCCN = RTCH success end
= assignment success + incoming (HO+DR) success - outgoing HO
= MC718 + (MC717A+MC717B) - MC712
rtch incoming (HO+DR) success is also counting the intracell HO, so they are included in "rtch outgoing HO success"
in this example, intracell HO = 0

4 Which KPI?
RTCH Drop Rate
RTCH drop rate (RTDR) = Call drop / RTCH success begin

100 inc HO
100 N.A.
150 out HO
10 Drops
cell n1
cell n2
cell S
RTCH success begin = rtch assignment success + rtch incoming (HO+DR) success
- rtch intracell HO success
RTDR = 10 / (100 + 100) = 5%
1 4 30

GQSCDN = call drop

= drop radio + drop TC + drop internal BSS + drop HO + drop Preemption
= MC736 + MC739 + MC14C + MC621 + MC921C
GTCQHCCN = RTCH success being
= assignment success + incoming (HO+DR) success - outgoing HO
= MC718 + (MC717A+MC717B) MC662

4 Which KPI?
TRX RTCH Drop (*) Rate
TRX Radio DR = Call drop radio / RTCH success

50 inc HO
50 N.A.
?? out HO
5 Radio Drops
cell n1
cell n2
cell S
(TRX 3 only)
RTCH success = rtch assignment success + rtch incoming (HO+DR) success
TRX Radio DR = 5 / (50 + 50) = 5%

(and same formula for TRC HO drops and TRX RTC drops)
1 4 31

Number of outgoing HO cannot be counted per TRX !

Number of BSS Internal drops cannot be counted per TRX !
Therefore : not possible to have a global drop rate per TRX (only radio, rtc or HO), and not possible to take into
account outgoing HO
GTCQHCCN = RTCH success
= assignment success + incoming (HO+DR) success (intracell, intercell)
= MC718 + (MC717A+MC717B)

4 Which KPI?
Choice of "Cell Level" KPI
Choosing a drop rate is simple

Let's have a look at a "highway" cell
Cells
NA Success
Inc HO
Success
Out HO
Success
Drops
CDR
RTCH DR
Highway
cell
1 000
15 000
12 000
3 000
75.0%
18.8%
Village cell
15 000
1 000
800
3 000
19.7%
18.8%
The amount of TCH's in the highway cell is about 16000

There only 3000 drops RTCH DR shows the reality !
Cell KPI is RTCH Drop Rate !
1 4 32

When there is only a little amount of HO transiting through the cell, the difference between CDR and RTCH DR is
small.

4 Which KPI?
Choice of "High Level" KPI
Let's have a look at a BSC

Cells
NA
Success
Inc HO
Success
Out HO
Success
Drops
CDR
RTCH DR
Cell A
1 000
15 000
12 000
3 000
75.0%
18.8%
Cell B
15 000
1 000
800
3 000
19.7%
18.8%
Cell C
19 000
11 800
15 000
500
3.2%
1.6%
BSC
35 000
27 800
27 800
6 500
18.6%
13.6%
The amounts of incoming HO and outgoing HO tend to be equal over a

large number of cells (a BSC, a LAC, etc)
Because "Inc HO" in a cell is "Out HO" in a neighbour cell
Only approximation are external HO which are not "balanced"
High Level KPI is Call Drop Rate !
1 4 33

An outgoing HO in cell A is probably an incoming HO in cell B !

Amount of TCH in the BSC = 35.000
Amount of Drops = 6.500
6.500 / 35.000 = 18.6%

4 Which KPI?
Alc_Mono_Call "CDR"
1 4 34

Report : Alc_Mono_Call

4 Which KPI?
Call Drop - Exercise
Alerting/Connection: TCH drop

1) For a Radio TCH drop, give the message and the cause. Extract a call with this cause.
Can you say if it is occurring during the communication phase?
2) Find a TCH drop due to Handover and extract the call.

3) Find a TCH drop due to TC problem and extract the call:
Can you identify PCM, CIC?
How many TC PBs are there in this Trace?
Any remark about PCM and CIC?
Time allowed:
15 minutes
1 4 35


1 4 36


Generalities
Since B10
Alternative classification of call drops : the BSC tries to associate a "radio

problem" (too low level, too bad quality, etc.) to each call drop.
Each time a call drop happens, the BSC compares the last measurement
average with all HO causes :
According to HO thresholds (Telecom Parameters)
If several causes are eligible, only the one with the highest priority is
counted
Not all drops can be classified. Sometimes the call is dropped while the last
averaged measure doesn't verify a HO cause.
Note: They are counted in parallel to the call drop causes studied before !
In other words:
MC928a + MC928b + MC928c + MC928d + MC928e + MC928f + MC928g + MC928h + MC928i
total number of call drops
1 4 37


Thresholds for Detection
Condition to trigger a reported HO cause

Condition verified by last MS measurements
Cause to be reported in
counters
AV_RXQUAL_UL_HO > L_RXQUAL_UL_H + OFFSET_RXQUAL_FH AND

AV_RXLEV_UL_HO <= RXLEV_UL_IH
Too low quality in UL
AV_RXQUAL_DL_HO > L_RXQUAL_DL_H + OFFSET_RXQUAL_FH AND

AV_RXLEV_DL_HO <= RXLEV_DL_IH
Too low quality in DL
AV_RXQUAL_UL_HO > L_RXQUAL_UL_H + OFFSET_RXQUAL_FH AND

AV_RXLEV_UL_HO < L_RXLEX_UL_H
Too low level in UL
AV_RXQUAL_DL_HO > L_RXQUAL_DL_H + OFFSET_RXQUAL_FH AND

AV_RXLEV_DL_HO < L_RXLEX_DL_H
Too low level in DL
AV_RANGE_HO > U_TIME_ADVANCE
Too long MS-BS distance
AV_RANGE_HO <= L_TIME_ADVANCE
Too short MS-BS distance
AV_RXQUAL-UL_HO > THR_RXQUAL_CAUSE_15 + OFFSET_RXQUAL_FH

AND AV_RXLEV_UL_HO > RXLEV_UL_IH
Too high interference in the

uplink
AV_RXQUAL-DL_HO > THR_RXQUAL_CAUSE_16 + OFFSET_RXQUAL_FH

AND AV_RXLEV_DL_HO > RXLEV_DL_IH
Too high interference in the

downlink
1 4 38
Priority

Available from B10

It can be seen in NPO (indicator call drop causes)
The BSC calculates the average value of AV_RXQUAL_UL_HO and AV_RXLEV_UL_HO as following:
If window_size is full, then the average values are calculated by using the Window_Size, otherwise, the average
values are calculated by using the number of received measurements.

Counters
Counters for each Handover cause detected
Shot name
Name
Definition
MC928a
NB_TCH_DROP_CAUSE_TOO_LOW_QUALITY_UL
Number of TCH drops due to Cause 2 (Too low quality in UL)
MC928b
NB_TCH_DROP_CAUSE_TOO_LOW_LEVEL_UL
Number of TCH drops due to Cause 3 (Too low level in UL)
MC928c
NB_TCH_DROP_CAUSE_TOO_LOW_QUALITY_DL
Number of TCH drops due to Cause 4 (Too low quality in DL)
MC928d
NB_TCH_DROP_CAUSE_TOO_LOW_LEVEL_DL
Number of TCH drops due to Cause 5 (Too low level in DL)
MC928e
NB_TCH_DROP_CAUSE_TOO_LONG_MS_BS_DIS
TANCE
Number of TCH drops due to Cause 6 (Too long MS-BS distance)
MC928f
NB_TCH_DROP_CAUSE_TOO_SHORT_MS_BS_DI
STANCE
Number of TCH drops due to Cause 22 (Too short MS-BS

distance)
MC928g
NB_TCH_DROP_CAUSE_TOO_HIGH_INTERFERE
NCE_UPLINK
Number of TCH drops due to Cause 15 (Too high interference

level on the uplink path)
MC928h
NB_TCH_DROP_CAUSE_TOO_HIGH_INTERFERE
NCE_DOWNLINK
Number of TCH drops due to Cause 16 (Too high interference

level on the downlink path)
MC928i
NB_TCH_DROP_OTHER_CAUSES
Number of TCH drop due to other causes than above
1 4 39


Indicators
Indicators
Formulae
Unit
Call_drop_DL_Interference_rate
Call_drop_DL_Interference / RTCH_success_end
Call_drop_DL_Level_rate
Call_drop_DL_Level / RTCH_success_end
Call_drop_DL_Quality_rate
Call_drop_DL_Quality / RTCH_success_end
Call_drop_Long_Distance_rate
Call_drop_Long_Distance / RTCH_success_end
Call_drop_Other_Causes_rate
Call_drop_Other_Causes / RTCH_success_end
Call_drop_Short_Distance_rate
Call_drop_Short_Distance / RTCH_success_end
Call_drop_UL_Interference_rate
Call_drop_UL_Interference / RTCH_success_end
Call_drop_UL_Level_rate
Call_drop_UL_Level / RTCH_success_end
Call_drop_UL_Quality_rate
Call_drop_UL_Quality / RTCH_success_end
1 4 40

Available since B10.

Alc Mono Drop Causes

Call drop radio causes - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone: Global - Medium)
160
1.40%
140
1.20%
120
DL_Level
100
0.80%
DL_Interference
%
nb
DL_Quality
1.00%
80
0.60%
60
0.40%
40
0.20%
0.00%
16
/0
5/
20
17
09
/0
22
5/
20
22
09
:0
17
0
/0
00
5/
00
20
:0
17
09
0
/0
02
5/
20
02
17
09
:0
0
/0
04
5/
20
04
09
:0
17
0
/0
06
5/
0
20
6:
17
09
00
/0
08
5/
20
08
09
17
:0
0
/0
1
5/
0
20
10
:0
09
17
0
/0
12
5/
12
20
:0
09
17
0
/0
14
5/
20
14
17
:0
09
0
/0
16
5/
20
16
:0
09
17
0
/0
18
5/
18
20
:0
09
0
20
20
:0
0
20
1 4 41


UL_Quality
UL_Level
UL_Interference
Short_Distance
Other_Causes
Long_Distance
% Call_drop_HO
% Call_drop_radio
1 4 42


BSS and User point of view

Exercise: Fill-up the empty cells with the name of the indicator that fully represents the success or unsuccess of each phase
Call Phases
User QoS
BSS QoS
SDCCH Assign
Unsuccess
Rate
1 Radio Link Establishment
Call setup
success rate
2 SDCCH phase
End to End CSSR
3 TCH Assignment
4 Alerting / Connection phase

RTCH Drop Rate
5 Call phase
1 4 43
Call Drop Rate

The indicators computation can be performed from several counters or by a simple counter mapping.
Example:
call drop rate = Call Drop nb / Call nb = f(counters)
call drop = Call drop nb = 1 counter

Summary
TYPICAL CALL FAILURES: summary
A interface
Call stage
Radiolink
establishment
Cause field
no message
- radio interface failure
- O&M intervention
- no radio resource avalaible
Assignment Failure - Radio Interface Failure
Clear Request
SDCCH phase
TCHassignment
Alerting/connection Clear Request

callestablished

- radio interface messagefailure
-equipmentfailure
- O&M intervention
- preemption

SDCCH Phase
TCH assignment
Alerting/CNX Phase
Related problem
- SDCCH congestion
- radio problem
- Dummy rach
- radio problem
- BSS system HW/SW pb
- recovery/operator
- TCH congestion
- Radio problem
- radio problem
- HO failurew/oreversion
- Transcoder failure
- operator action/recovery
- BSS system HW/SW pb
-preemption
LAPD counter "L1.18" : time during which the LapD link (= RSL) is congested
1 4 44

When the BSC is congested on the downlink, some messages are discarded. This may result for example in call
establishment failures, loss of paging messages or delay in handover procedures.
1 LapD counter that indicates the time an LapD link is congested is created to analyze the cause of a degraded
quality of service. This counter is implemented in type 7 and thus is only available in a detailed measurement
campaign.
Counter: L1.18: TIME_LAPD_CONG
Definition: Time in seconds during which the LapD link is congested in transmission in the BSC.

List of KPIs for Management
Only for Call Setup and Call Phases,

Exercise: List the indicators that should be communicated to the GSM
Managers, looking at BSC level.
1.
2.
3.

End-to-End Call Setup Success Rate
Call Drop Rate
Next slide's exercise: List the "detailed" indicators that should be monitored
constantly by "Performance Monitoring" Engineers, looking at cell level.
1 4 45


List of KPIs for Monitoring
Only for Call Setup and Call Phases,

Exercise: List the indicators that should be monitored constantly by
"Performance Monitoring" Engineers, looking at cell level.
1.
SDCCH Assign Unsuccess Rate
SDCCH Assign Request
SDCCH Assign Congestion Rate
SDCCH Assign Fail Radio Rate
SDCCH Assign Fail BSS Rate
2.
B10
End-to-End Call Setup Success Rate
1.
SDCCH Drop Rate
SDCCH Assign Success
SDCCH Drop BSS Rate

2.
RTCH Assign Unsuccess Rate
RTCH Assign Request
RTCH Assign Congestion Rate
RTCH Assign Prep Fail BSS Rate
RTCH Assign Fail Radio Rate
RTCH Assign Fail BSS Rate
1 4 46
3.
RTCH Drop Rate
RTCH Assign Success
RTCH Drop Radio Rate
RTCH Drop HO Rate
RTCH Drop BSS Int Failure Rate
RTCH Drop BSS Remote TC Rate
RTCH Drop Preemption Rate
Call Drop End User Rate

B10
Call Drop Specific Causes


1 4 47


Objective
Beware of traps and restrictions about some global indicators
So as to be able to provide a reliable interpretation
1 4 48


CSSR & CDR
CALL SETUP SUCCESS

The radio link establishment phase is not taken into account, because:
most of failures during RLE are due to ghost RACH
the MS is attempting MAX_RETRANS+1 times before giving up
difficult to assess subscriber's impact, anyhow very low
CALL DROP
For BSS, the last stage is considered as established, although it is not the
cause from a user point of view
If a TCH drop occurs during this phase
for the user, it is a setup failure
for the OMC-R indicators, counted as a call drop
1 4 49


Call Duration
IMPACT OF CALL DURATION

The longest a call is, the highest the risk to have a drop is
If statistics are done on abnormally long or short calls, the result can be less
accurate
Typical case: drive test
Typical call duration: 80/90 seconds in most European countries
1 4 50


Mobility
IMPACT OF MOBILITY
Most of drop problems are due to mobility
Usually 2/3 of calls are static (no HO will be done)
For example, if 40 drops are observed for 1000 calls
40/1000 = 4% of global call drop

but most of call drops are generated by "moving calls"
40/(1000*1/3) = 40/333 = 12 % of call drop rate for moving call

0 % for static call
Typical trap when comparing drive tests results with OMC-R statistics
1 4 51


Exercise
Case
Conclusion
Global call drop : 2%
For 1 call of 20 mins,

risk of drop is 2%
In 1 BSS, some transcoders are faulty :

as soon as TCH are established on these
TC, they are lost
The call setup success

rate indicator will be
increased due to this
problem
In 1 network, drive test are showing a

general call drop rate of 7%.
OMC-R call drop indicator is giving 2,1%
OMC-R indicator is
erronous (drive test is
the reality)
In 1 network, global call setup success

rate is 92%
For moving call, call

setup success rate will
be about 76%
In a pedestrian zone, 80% of calls are

static measured call drop is 1,7%
For taxi, call done in

taxi in this zone will be
dropped at 5,1%
OK / NOK ?
NOK
Time allowed:
15 minutes
1 4 52


Why
Call duration is more than average
1 4 53


Exercise 1
Is
this network OK?
Name
Value
SDCCH congestion rate
1%
SDCCH drop rate
3%
TCH assignment failure rate
2%
Call drop rate
1%
Call setup success rate
96%
Call success rate
94%
Efficiency of outgoing HO
92%
Efficiency of incoming HO
93%
HO cause distribution better / level / quality
70 / 20 / 10
RTCH availability
98%
Time allowed:
5 minutes
1 4 54


Exercise 2
Can
one say that:
all indicators are OK?

the coverage of the network is 95%?
the call success of all the cells is 95%
(minimum)?
Time allowed:
5 minutes
1 4 55
Name
Value
5%
SDCCH drop rate
2%
1%
Call drop rate
1%
97%
Call success rate
95%
92%
92%
HO cause distribution better / level /

quality
70 / 20 / 10
RTCH availability
98%


Exercise 2
Results
of field tests on a network
Is the network better if GQSCDR = 2%?
Name
Value

SDCCH drop rate
Call drop rate
4,6%
92%
Call success rate

Time allowed:
5 minutes
HO cause distribution better / level /

quality
RTCH availability
1 4 56


Exercise
Indicator
Value
1- SDCCH congestion
10%
2- Call drop rate
5%
3- Call success rate
95%
4- Efficiency of outgoing HO
91%
5- RTCH availability
93%
6- TCH Assignment failure
2,4%
7- SDCCH drop
2%
8- HO cause distribution (ratio of

better cell)
45%
9- Call setup success rate
88%
10- SDCCH drop rate
1%
OK / NOK ?
Time allowed:
15 minutes
1 4 57


Impact

for this module
1 4 58


End of Module
Communication Phase
1 4 59


Section 1
Module 5
Handover Indicators
GSM B11

Blank Page
152
B11 GSM QoS Monitoring Handover Indicators

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
Last name, first name
First edition

Module Objectives
Explain what are the main Handover counters and indicators provided by the
Alcatel-Lucent BSS in order to monitor the quality of handovers
153


154


Table of Contents
1 Handovers Overview
Description
Types
2 Intra-Cell Handovers
Intracell HO - Success
Failure Causes
Failure - Congestion
Failure - Radio Failure with ROC
Failure - Radio Failure with Drop
Failure Other Drops "BSS"
Main Counters
3 Internal Intercell Handovers
Internal HO Success (Async)
HO COMMAND message
Incoming Internal HO - Failures
Incoming Internal HO - Congestion
Incoming Internal HO - Radio Failure
Incoming Internal HO - Counters
Incoming Internal HO - Indicators
Outgoing Internal HO - Failures
Outgoing Internal HO - Radio Failure ROC
Outgoing Internal HO - Radio Failure Drop
Outgoing Internal HO - Counters
155
Outgoing
Internal
HO - Indicators
Handover Indicators
Intra-Cell
HO / Internal HO - Exercise
4 External Intercell Handovers
External HO - Success
External HO - Failures
Incoming External HO - Congestion
Incoming External HO TTCH (CIC) Congestion
Incoming External HO - Radio Failure
Incoming External HO - Counters
Incoming External HO - Indicators
Outgoing External HO - Failures
Outgoing External HO - Radio Failure with ROC
Outgoing External HO - Radio Failure Drop
Outgoing External HO - Counters
Outgoing External HO - Indicators
External HO - Exercise
5 Handovers QoS per Adjacency
Type 180 Counters
Type 180 Indicators
Type 26: TCH outgoing handover per adjacency
Type 27: 2G TCH incoming handover per adjacency
Type 27 Indicators
6 Inter-PLMN and Inter-RAT
Inter-PLMN HO Description
Inter-PLMN Indicators
2G-3G Indicators
Handover Cause Distribution
Handover Standard Cause Distribution
Outgoing Handover Success Rate
Incoming Handover Success Rate

Page
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
50
51
52
53
54
55
56
57
58
59
60
61
62

Page

Handover Failure Main Causes
63
156


157


Description
Handovers are detected & prepared by the BSC

Algorithms are checked
Radio resources are allocated
MS moves from 1 TCH in the Serving Cell to 1 TCH in the Target Cell
BTS
BSC
CELL (S)
CELL (T)
channel activation
handover command
158
Radiolink Measurements
Active Channel Preprocessing
HO Detection
Candidate Cell Evaluation
HO Preparation
HO Execution

note: Handovers are not only from TCH to TCH:

HO SDCCH to SDCCH (SDCCH HO)
HO SDCCH to TCH (=directed retry)

Types
New TCH is in another

TRX of the current cell
Intracell
Intercell
New TCH is in another

cell
Serving and Target cells

belong to the same BSC
(intra-BSC)
Internal
External

belong to different BSCs
(inter-BSC)
Point of view from the

target cell
Incoming
Outgoing
Point of view from the

serving cell
Seving and Target cells

are synchronized
Synchronous
Async.

are not synchronized
If the MS doesn't leave

the current channel, a
call drop will occur
Emergency
Better Cell
The Target cell is better

than the Serving cell
159


1 5 10


Intracell HO - Success
MS
BSC
(detection of intracell HO) MC870
Cell
Physical Context Request
*TC*
MSC
T9108
Physical Context Confirm

Channel Activation (new ch)
T9103
Channel Act. Ack (new ch)

Assignment Command
Assign Command
SABM (new ch)
UA (new ch)
MC871
T3107
Establish Indication (new ch)
Assign Complete (new ch)
Assign Complete
MC662
Handover Performed
RF Channel Release
BSC Shared DTM Info Indication

only for DTM-capable MS
RF Channel Release Ack

1 5 11
MFS

Both SDCCH and TCH are counted together.

The T3107 timer is also used as the guard timer of the channel change procedure during an intra cell handover. The
default value for T3107 is 14 seconds.
The BSC will send BSC Shared DTM INFO Indication to inform the MFS the successful end of the procedure if the
conditions below are fulfilled:
EN_DTM = enabled
The MS is DTM capable
by default : T3107 = 14sec

Failure Causes
Handover Preparation:
Congestion
Preparatio Failure
HO_Cell_cong
HO_Cell_prep_fail *
Handover Execution:
Reversion to old channel
Drop radio
Drop due to BSS problem
HO_Cell_ROC
HO_Cell_drop_radio
HO_Cell_drop_BSS *
(*) No specific counter
1 5 12


B11
Failure - Congestion
MS
BSC
Cell
Measurement Report
Measurement Result
(detection of intracell HO) MC870
(no free channel)
MC561
TCH
MC101
/ SDCCH
MC561:
1
B1
2
MR
In MX BSC, this counter is incremented whenever an intra-cell TCH handover

cannot be performed due to the TCH processing capacity of CCP reaches the
limit defined by the MAX_TCH_PER_CCP parameter. In this case, MC926 is
also incremented by one.
In IP mode, this counter is increased by 1 if:

- the cell mapped on a BTS is in IP congestion status;
- or the TCH processing capacity of AbisBTSGroup reaches the limit defined
by the NB_MAX_ACTIVE_TCH_TS parameter
1 5 13

From B7, MC561 replaces MC61 (B6).

As the counting of the Abis-TCH congestion case was in restriction in B8: MC61(B6) = MC561(B7)

Failure - Radio Failure with ROC

MS
Assign Command (old)
SABM (new)
T200_TF
try
200ms
N200_TTF
times
BSC
Cell
Assignment Command
MC871
T3107
Establish Indication
UA (new)
SABM (new)
200ms
UA (new)
SABM (new)
UA (new)
etc etc etc
Assign Failure (old)
Assign Failure
MC667
stop
Physical Context Request (new)

Physical Context Confirm (new)
RF Channel Release (new)
RF Channel Release Ack (new)
1 5 14

In this example, the Downlink path on the new channel is faulty (interference, path unbalance ).
It is also possible the MS immediately sends an Assign Failure (without even attempting to connect to the new
channel).
N200_TTF = 34
T200_TF = 200ms
200 * 35 = 7seconds
MC667 = C107 (sdcch intracell ho fail roc) + C67 (tch intracell ho fail roc)

Failure - Radio Failure with Drop
MS
BSC
Cell
Assign Command (old)
Assignment Command
MC871
Channel release of
old and new channels
MC663
1 5 15

MC663 = C103 (sdcch) + C63 (tch)

T3107
Failure Other Drops "BSS"
Based on missing successes:

HO_Cell_drop_BSS =
HO_Cell_allocated - HO_Cell_success - HO_Cell_drop_radio - HO_Cell_ROC
Another counter is linked to various causes of drops during HO

preparation and execution phases:
MC14a (Call_drop_HO_Prep_Exec_BSS_failure) is incremented when :
TCH Channel Activation is acknowledged negatively
Channel Activation procedure (T9103) expires
LapD failure, or Abis failure, or BSC boards failure
48.058 ERROR REPORT message with a cause value of "O&M intervention" or
"message sequence error" is received on Abis interface from either the
serving or the target cell
48.058 CONNECTION FAILURE INDICATION message with a cause value of
"remote transcoder failure" during the Channel Activation procedure
1 5 16

Intra cell HO failures due to BSS problems are deduced from other counters.

Main Counters
HO FAIL. CASES > intracell HO counters

REQUEST
Preparation Failure
ATTEMPT
SUCCESS
CONGESTION
Execution Failure
INTRACELL Handover
Preparation
Execution
BSS PB
Request
MC870
Congestion
BSS Pb
MC561+MC101
MC870-MC871-(MC561+MC101)
Attempt
MC871
Reversion old channel MC667

Drop radio
MC663
BSS Pb
MC871-MC662-MC667-MC663
Success
MC662
1 5 17


REVERSION OLD CHANNEL
DROP RADIO
DROP BSS
1 5 18


Internal HO Success (Async)

MS
TCH
Serving Cell Target Cell
speech
BSC
(detection of intercell HO) MC655a MC830
Channel Activation (new ch)
MSC
T9103
Channel Act. Ack (new ch)
(opt) TFO Modification Req

HO Command
MC660
MC871
MC656
MC652
T3103
HO Access * 4
HO Detection
SABM (new ch)
Establish Indication
UA (new ch)
Assign Complete (new ch)
TCH
Handover Complete
Handover Performed
speech
(old channel release)
1 5 19
BSC Shared DTM Info Indication

only for DTM-capable MS
MFS

MC830=C230 (tch) + C330 (sdcch)

After the HO PERFORMED is sent to the MSC.
if DTM is enabled in the old cell, it sends a BSCGP BSC shared DTM info indication (CS_Flag = 0) to the MFS.
if DTM is enabled in the new cell, it send a BSCGP BSC shared DTM info indication (CS_flag = 1) to the MFS.
The MFS in the old cell deletes the MS context and creates an MS context according to the information received in
the BSCGP BSC shared DTM info indication.
In case of Sync HO, the HO COMMAND contains a valid timing advance value, so that the MS will use this timing
advance in the target cell.
If the HO is not sync, then the HO COMMAND indicates that the HO is async, and the MS will send the HO ACCESS
with TA=0. The target BTS will need to compute the TA.

HO COMMAND message
The TCH in the Target cell is fully described in the HO Command
BCCH, BCC, NCC

TCH Frequency (or Frequency Hopping MA List, MAIO, HSN, etc.)
TS Number
Ciphering
Speech Codec (only for phase 2 MS)
Timing Advance information (if Sync HO)
TCH
HO Command
1 5 20


Serving Cell
Incoming Internal HO - Failures
Causes of Failures :
Handover procedure from the target cell point of view
Congestion: no RTCH available in the target cell
"Other" problem (no specific counter)
Handover Execution:
Radio problem: the MS fails to access the new channel
which can lead to a "drop" or a "reversion to old channel" (cf. outgoing indicators)
BSS problem (no specific counter)
1 5 21


Incoming Internal HO - Congestion
MS
Serving Cell
MEAS REPORT
----------------------------->
Serving BSC
MSC
MEASUREMENT RESULT
--------------------------------------------------------------> MC830
No free TCH
MC551
1 5 22

From B7, MC551 replaces MC51of B6.

As the counting of the Abis-TCH congestion case was in restriction in B8: MC51(B6) = MC551(B7)

Incoming Internal HO - Radio Failure
MS access problem
MS
Serving cell
Target Cell
BSC
HO CMD
HANDOVER COMMAND
<----------------------- <------------------------------------------------------------------------ start T3103
HANDOVER ACCESS
MC660
------------------------------------------------------------->
------------------------------------------------------------->
HO DETECTION
PHYSICAL INFORMATION
---------------------------------->
<------------------------------------------------------------- start T3105
SABM
-------------------------------------------------------------> ESTABLISH INDICATION
UA
---------------------------------->
<------------------------------------------------------------- stop T3105
HANDOVER COMPLETE
----------------------------------------------------- - - - -X
MS
serving cell
target cell
BSC
SABM
MEAS REP
----------------------->
MEASUREMENT RESULT
UA
------------------------------------------------------------------------> ----------------------->
------------------------------------------------------------------------>
<----------------------CHANNEL ACTIVATION
HO FAILURE
HANDOVER FAILURE
<--------------------------------------------------------> ------------------------------------------------------------------------> MC653
CHANNEL ACTIV ACK
Release of new channel
---------------------------------->
MSC
HO CMD
HANDOVER COMMAND
<----------------------- <------------------------------------------------------------------------ start T3103
MC660
SABM
-----------x
T3103 expiry
MC653
1 5 23

All incoming internal HO failures due to radio problems are counted in the same counter MC653.
Both radio failures with Reversion Old Channel and radio drop are counted together.

Incoming Internal HO - Counters
REQUEST
ATTEMPT
SUCCESS
Preparation Failure
Execution Failure
CONGESTION
INCOMING INTERNAL Handover

Preparation Request
BSS PB
MC830
Congestion
BSS Pb
MC551+MC91
MC830-MC831-(MC551+MC91)
Attempt
MC831
Radio (MS access problem)

BSS Pb
MC653
MC831-MC652-MC653
Success
MC652
MS ACCESS PB
Execution
1 5 24


BSS PB
Incoming Internal HO - Indicators
HO_Inc_BSC_request
HO_Inc_BSC_allocated
HO_Inc_BSC_cong
HO_Inc_BSC_prep_fail
HO_Inc_BSC_success
HO_Inc_BSC_fail_radio
HO_Inc_BSC_fail_BSS
1 5 25


Handover Statistics INDICATORS > Incoming handover > Incoming Intra BSC
GHOIBEFR: efficiency of the incoming internal HO execution
GHOIBCGR: rate of incoming internal HO failures due to congestion
GHOIBPFR: rate of incoming internal HO failures due to BSS during the preparation phase
GHOIBFLRR: rate of incoming internal HO failures due to radio problems
GHOIBFLBR: rate of incoming internal HO failures due to BSS during the execution phase

Outgoing Internal HO - Failures
Cases of Failures:
Handover procedure from the serving cell point of view
Preparation Failures (no details)
Handover Execution:
radio problem: the MS reverts to the old channel
radio problem: the MS drops
1 5 26


Outgoing Internal HO - Radio Failure ROC

MS
Serving cell
Target Cell
BSC
HO CMD
HANDOVER COMMAND
<----------------------- <------------------------------------------------------------------------ start T3103
HANDOVER ACCESS
MC660
------------------------------------------------------------->
------------------------------------------------------------->
HO DETECTION
---------------------------------->
<------------------------------------------------------------- start T3105
SABM
UA
---------------------------------->
<------------------------------------------------------------- stop T3105
HANDOVER COMPLETE
----------------------------------------------------- - - - -X
SABM
----------------------->
UA
------------------------------------------------------------------------>
<----------------------HO FAILURE
HANDOVER FAILURE
-----------------------> ------------------------------------------------------------------------> MC657
1 5 27


Outgoing Internal HO - Radio Failure Drop

MS
serving cell
target cell
BSC
MSC
MEAS REP
----------------------->
MEASUREMENT RESULT
------------------------------------------------------------------------> MC655A
CHANNEL ACTIVATION
<---------------------------------CHAN ACTIV ACK
---------------------------------->
HO CMD
HANDOVER COMMAND
<----------------------- <------------------------------------------------------------------------ start T3103
MC660
SABM
----------x
Release of old and new TCH
T3103 expiry
MC658
Clear_request
------------------------>
Clear_command
<------------------------
clear_request: ask the MSC to release the connection

In case of call drop due to HO, the cause is "radio interface message failure"
(for Alcatel-Lucent)
1 5 28


Outgoing Internal HO - Counters
HO FAIL. CASES > Outgoing internal HO counters

REQUEST
ATTEMPT
SUCCESS
Preparation Failure
Execution Failure
CONGESTION
OUTGOING INTERNAL Handover

Preparation
Execution
BSS PB
Request
MC655A
Any preparation failure
MC655A-MC660
Attempt
MC660
Reversion old channel

Drop radio
BSS Pb
MC657
MC658
MC660-MC656-MC657-MC658
Success
MC656
1 5 29

DROP RADIO


BSS PB
Outgoing Internal HO - Indicators
HO_Out_BSC_request
HO_Out_BSC_required
HO_Out_BSC_success
HO_Out_BSC_prep_fail
HO_Out_BSC_ROC
1 5 30
HO_Out_BSC_drop_radio
HO_Out_BSC_drop_BSS


Handover Statistics INDICATORS > Outgoing handover > Outgoing Intra BSC
GHOOBRQR: efficiency of the outgoing internal HO preparation
GHOOBEFR: efficiency of the outgoing internal HO execution
GHOOBOCR: rate of outgoing internal HO failures due to radio problems with Reversion Old Channel
GHOOBCDRR: rate of outgoing internal HO failures due to radio problems with drop
GHOOBCDR: rate of incoming internal HO failures with drop (radio + BSS)

Intra-Cell HO / Internal HO - Exercise
With K1205, find in the PAIB29.REC file:

1) One case of intra-cell failure with reversion
2) One case of Internal handover success
Identify the target cell
Identify the serving cell (in CR for call establishment)
3) One case of Internal handover failure with reversion

4) One case of Internal handover failure without reversion
Time allowed:
15 minutes
1 5 31


1 5 32


External HO - Success
MS
serving_cell
BSC
MSC
BSC
target_cell
MS
- MEAS_REPORT ->
------- MEAS_RESULT -------->
MC645A ------ HO_REQUIRED ---------->
MC462A
<------------------------- HO_COMMAND -----------------------------------------------------MC650 Start T8

MC462B
----------CR (HO_REQUEST) -----> MC820 MC463A

<--------- CC --------------------------- CHANNEL_ACTIVATION ------>
<- CHANNEL_ACT_ACK------------<----- HO_REQUEST_ACK -------- Start T9113
(HO_COMMAND)
MC821 MC463B
<------ HO_DETECTION-------------<-- HO_DETECTION --------------
--- PHYSICAL_INFO -->
<----- ESTABLISH_INDICATION ----
<--- HO_COMPLETE --------------MC462C

Release of TCH
<---- CLEAR_COMMAND -----MC646 Cause: HO_SUCCESSFUL

Stop T8
1 5 33
<---- HO_ACCESS ----<---- HO_ACCESS -----
<--- SABM ------------------- UA -------------->
<----------- HO_COMPLETE ---------------------------------------Stop T9113

MC642
MC463C

Both SDCCH and TCH are counted together.

From B7, MC645A replaces MC645 of B6.
MC645a is only counting HANDOVER REQUIRED messages that are linked to a handover trial and not those that are linked to the
update of the candidate cell list for handover / directed retry. This is leading to a more accurate computation of the External
outgoing HO success rate.
Only Outgoing inter PLMN HO is allowed.
6 counters provide information for "Inter-PLMN HO" (Incoming and Outgoing) (From B8)
MC462a (equivalent of MC645A for intra PLMN external HO)
Number of inter-PLMN TCH outgoing handovers or directed retry requests:
HANDOVER REQUIRED sent to the MSC for an external TCH HO or an external DR triggered towards a cell belonging to a PLMN
different from the PLMN of the serving cell.
MC462b (equivalent of MC650 for intra PLMN external HO)
Number of inter-PLMN TCH outgoing handovers or directed retry attempts:
HANDOVER COMMAND sent to the MS on Abis for an external TCH HO or an external DR triggered towards a cell belonging to a PLMN
different from the PLMN of the serving cell.
MC462c (equivalent of MC646 for intra PLMN external HO)
Number of inter-PLMN TCH outgoing handovers or directed retry successes:
CLEAR COMMAND with Cause "Handover successful" received from the MSC for an external TCH HO or an external DR triggered
towards a cell belonging to a PLMN different from the PLMN of the serving cell.
MC463a (equivalent of MC820 for intra PLMN external HO)
Number of inter-PLMN TCH incoming handovers or directed retry requests:
HANDOVER REQUEST received from the MSC for an external TCH HO or an external DR triggered towards the target cell from a
serving cell belonging to a PLMN different from the PLMN of the target cell.
MC463b (equivalent of MC821 for intra PLMN external HO)
Number of inter-PLMN TCH incoming handovers or directed retry attempts:
HANDOVER REQUEST ACK sent by the target BSC containing the HANDOVER COMMAND for an external TCH HO or an external DR
triggered towards the target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.
MC463c (equivalent of MC642 for intra PLMN external HO)
Number of inter-PLMN TCH incoming handovers or directed retry successes:
HANDOVER COMPLETE received from the MS on Abis for an external TCH HO or an external DR triggered towards the target cell from
a serving cell belonging to a PLMN different from the PLMN of the target cell.
Note than all other (previous) counters related to HO continue to be based on Intra PLMN only.
External HO - Failures
Cases of Failures, from the target cell perspective (incoming):
HO_Inc_MSC_request
HO_Inc_MSC_allocated
HO_Inc_MSC_cong
HO_Inc_MSC_success
1 5 34
HO_Inc_MSC_no_cic_alloc
HO_Inc_MSC_fail_radio
HO_Inc_MSC_prep_fail
(deduced)
HO_Inc_MSC_fail_BSS
(deduced)

"deduced" : shows all the failures that were not counted by dedicated counters, by computing the missing successes.

Incoming External HO - Congestion
MS
serving_cell
BSC
MSC
BSC
- MEAS_REPORT ->
------- MEAS_RESULT -------->
MC645A ------ HO_REQUIRED ------->
( < -HO_REQUIRED_REJECT-)
1 5 35
----------CR (HO_REQUEST) ----->
MC820
< ----- HO_FAILURE --------------Cause: no radio resource available
MC541A

In case of Mx-BSC, the Congestion cases includes:

- RTCH timeslot congestion
- "target" Mx-BSC CCP board capacity exceeded
- With Abis over IP (B11 MR3), when the Abis is congested.
(note: TDM Abis congestion cannot be seen with this counter)

target_cell
MS
Incoming External HO TTCH (CIC) Congestion
MS
serving_cell
BSC
MSC
BSC
- MEAS_REPORT ->
------- MEAS_RESULT -------->
MC645A ------ HO_REQUIRED ------->
----------CR (HO_REQUEST) ----->
MC820
< ----- HO_FAILURE --------------Cause: terrestrial circuit already allocated

Requested terrestrial resource unaivalable
BSS not equiopoed
MC41B
( < -HO_REQUIRED_REJECT-)
1 5 36


target_cell
MS
Incoming External HO - Radio Failure
HO FAIL. CASES > Incoming external HO fail: MS access problem

MS
serving_cell
BSC
MSC
BSC
target_cell
MS
- MEAS_REPORT ->
------- MEAS_RESULT -------->
MC645A ---- HO_REQUIRED ------->
----------CR (HO_REQUEST) ------------------->
< -------- CC --------------------------------------< ----- HO_REQUEST_ACK----------------------(HO-COMMAND) included
MC820
- CHANNEL_ACT ---------->
< --- CHA_ACT_ACK -------Start T9113
MC821
< -------------------------- HO_COMMAND -----------------------------------------------Sta rt T8

----- SABM -------->
< --- UA -------------
X --- HO_ACCESS ----X ---- HO_ACCESS -----
-- ESTABLISH_INDICATION->
MS ----- HO_FAILURE
serving_cell
(reversion to old channel)
BSC
------------------------------------------>
- MEAS_REPORT ->
------- MEAS_RESULT -------->
MSC
BSC
----- CLEAR_COMMAND ---------------------->

Radio interface fail : Reversion to old channel
----------CR (HO_REQUEST) ------------------->

< -------- CC ---------------------------------------
< ----- HO_REQUEST_ACK----------------------< -------------------------- HO_COMMAND ------------------------------------------------ HO-COMMAND) included

Sta rt T8
target_cell
Release of connection
MC820
< --- CHA_ACT_ACK -------Sta rt T9113
Start T9113
MC821
----- SABM --- X

----- SABM --- X
----- SABM --- X
T9113 expiry
MC643
1 5 37

All incoming external HO failures due to radio problems are counted in the same counter MC643.
Both radio failures with Reversion Old Channel and radio drop are counted together.

MS
MC643
Incoming External HO - Counters

REQUEST
ATTEMPT
Preparation Failure
NO CIC ALLOC
SUCCESS
Execution Failure
CONGESTION
BSS PB
INCOMING EXTERNAL Handover

Preparation Request
no CIC alloc
Congestion
BSS Pb
Execution
MC820
MC41b
MC541a+MC81
MC541+MC81
MC820-MC821-(MC541+MC81)
Attempt
MC821

BSS Pb
MC643
MC821-MC642-MC643
Success
MC642
1 5 38


MS ACCESS PB
BSS PB
Incoming External HO - Indicators
1 5 39


Handover Statistics INDICATORS > Incoming handover > Incoming Inter BSC
GHOIMEFR: efficiency of the incoming external HO execution
GHOIMCGR: rate of incoming external HO failures due to radio congestion (Air or Abis TCH)
GHOIMAMR: rate of incoming external HO failures due to CIC congestion (A TCH)
GHOIMPFR: rate of incoming external HO failures due to BSS during the preparation phase
GHOIMFLRR: rate of incoming external HO failures due to radio problems
GHOIMFLBR: rate of incoming external HO failures due to BSS during the execution phase
Inter PLMN Incoming External HO Indicators (from B8)

An indicator is created for each counter:
REQUESTS
ATTEMPTS
SUCCESS
In addition, these indicators show:
the success rate of incoming inter-PLMN HOs,
the ratio of incoming inter-PLMN HO to incoming intra-PLMN and inter-PLMN HO.

Outgoing External HO - Failures
Cases of Failures (Outgoing)

No detail available, only generic "preparation failures"
Handover Execution:
HO_Out_MSC_required
HO_Out_MSC_request
HO_Out_MSC_success
HO_Out_MSC_prep_fail
(deduced)
HO_Out_MSC_ROC
1 5 40
HO_Out_MSC_drop_radio


HO_Out_MSC_drop_BSS
(deduced)
Outgoing External HO - Radio Failure with ROC
MS
serving_cell
BSC
MSC
BSC
target_cell
MS
- MEAS_REPORT ->
------- MEAS_RESULT -------->
----------CR (HO_REQUEST) ------------------->

MC650
----- SABM -------->
< --- UA ------------- -- ESTABLISH_INDICATION->
----- HO_FAILURE (reversion to old channel) ------------------------------------------>
MC647
1 5 41
----- CLEAR_COMMAND ---------------------->



Outgoing External HO - Radio Failure Drop
In this case, no reversion to old channel detected
MS
serving_cell
BSC
MSC
BSC
target_cell
MS
- MEAS_REPORT ->
------- MEAS_RESULT -------->
----------CR (HO_REQUEST) ------------------->

MC650
----- SABM --- X
----- SABM --- X
----- SABM --- X

T8 expiry ----- CLEAR_REQUEST ->
MC648 Radio interface message fail
1 5 42


Outgoing External HO - Counters

REQUEST
ATTEMPT
SUCCESS
Preparation Failure
Execution Failure
CONGESTION
BSS PB
OUTGOING EXTERNAL Handover

Preparation
Execution
Request
MC645A
MC645A-MC650
Attempt
MC650

Drop radio
BSS Pb
MC647
MC648
MC650-MC646-MC647-MC648
Success
MC646

DROP RADIO
BSS PB
1 5 43


Outgoing External HO - Indicators
1 5 44

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS RELEASE:

Handover Statistics INDICATORS > Outgoing handover > Outgoing Inter BSC
GHOOMRQR: efficiency of the outgoing external HO preparation
GHOOMEFR: efficiency of the outgoing external HO execution
GHOOMOCR: rate of outgoing external HO failures due to radio problems with Reversion Old Channel
GHOOMCDRR: rate of outgoing external HO failures due to radio problems with drop
GHOOMCDR: rate of incoming external HO failures with drop (radio + BSS)
Inter PLMN Outgoing External HO Indicators (From B8)

An indicator is created for each counter:
REQUESTS
ATTEMPTS
SUCCESS
In addition, these indicators show:
the success rate of outgoing inter-PLMN HOs,
the ratio of outgoing inter-PLMN HO to outgoing intra-PLMN and inter-PLMN HO.

External HO - Exercise
In PAIB29.REC, extract (if available):

1)
2)
3)
4)
1 incoming external HO success

1 outgoing external HO success
1 incoming external HO failure
1 outgoing external HO failure
Time allowed:
15 minutes
1 5 45


1 5 46


Type 180 Counters
Some handover indicators available per couple of (serving, target)

cells permanently through PM type 180 counters
b
C40i(a,b)
3 counters for each (Serving,Target) adjacency:

- C400(S,T): Incoming handovers requested
to cell T from cell S
- C401(S,T): Incoming handovers attempted
to cell T from cell S
- C402(S,T): Incoming handovers successfully
performed to cell T from cell S
C40i(c,b)
C40i(c,d)
both internal and external inter cell handovers are counted

both SDCCH and TCH handovers are counted
d
e
C40i(f,d)
1 5 47

According to the definition of C40i counters:
C400(Sn,T) = MC820(T) + MC830(T)
C401(Sn,T) = MC821(T) +MC831(T)
C402(Sn,T) = MC642(T) + MC652(T)
where
Sn are the serving cells considering the incoming adjacencies to cell T.

MC820(T), MC821(T), MC642(T) are the counters relating to the incoming external handovers requested,
attempted and successfully performed to cell T.
MC830(T), MC831(T), MC646(T) are the counters relating to the incoming internal handovers requested,
attempted and successfully performed to cell T.

Type 180 Indicators
From these 3 counters, the following indicators are

computed:
Cell B
100
Cell A
150
200
10
220
Cell C
300
Fill up
Fill up
Matrix Inc request
Matrix Inc allocated
Matrix Inc success
100
80
40
Cell A - Cell C
10
10
Cell B - Cell A
150
Cell B - Cell C
220
Cel C - Cell A
300
30
Cell C - Cell B
200
Cell A - Cell B
1 5 48
Matrix Inc allocated Matrix Inc efficiency Matrix Inc unsuccess

rate
rate
rate
10
80/100
100%
40/80
100%
(100-40)/100
100%
30
10%
100%
10%

Note : in NPO, when n/a is seen in the table, it means "0" (= no HO were done during the period)

Type 180 Indicators [cont.]
The following indicators can be computed from PM Type 180 counters

in order to:
Detect the most important neighboring cells as per their traffic
Distribution of incoming handovers performed to cell T from serving cells Sn =
C402(Sx,T) / C402(Sn,T)
n
Ease the diagnosis of the bad handover performance of a cell

Global Success of incoming handovers to cell T from cell S
HOOASUR = C402(S,T) / C400(S,T)
Allocation Success of the incoming handover preparation to cell T from cell S
HOOACAR = C401(S,T) / C400(S,T)
Efficiency of the incoming handover execution to cell T from cell S
HOOAEFR = C402(S,T) / C401(S,T)
1 5 49


Handover Statistics > HO Statistics per couple of cells > Indicators with counter type 180
These indicators can also be used to check if a recently handover relationship is generating handover as expected.
They will also allow to identify the handover relationships which should be deleted since no (or very few)
handover is observed.

Type 26: TCH outgoing handover per adjacency
Some handover indicators are available per couple of (serving, target)

cells on demand for all outgoing adjacencies of a serving cell through
PM type 26 (40 cells since B8)
Tb
Target a
C720 Outgoing TCH handover attempts
Tc
C72i(S,Tc)
Serving
C721 Outgoing TCH handover successes.

C722 Outgoing TCH handover -execution radio failures with ROC
C723 Outgoing TCH handover -execution radio failures without ROC
C724 Outgoing TCH handover for an emergency cause
C72i(S,Te)
Te
C725 Outgoing TCH handover for a better cell cause
Tf
1 5 50
C727 Outgoing TCH handover for a traffic cause

C728 Outgoing TCH handover for FDR


Type 27: 2G TCH incoming handover per adjacency
Some handover indicators are available per couple of (serving, target)

cells on demand for all incoming adjacencies of a target cell through
PM type 27.
C730 Incoming 2G TCH handover attempts
Sb
Serving a
C731 Incoming 2G TCH handover successes.
Sc
C73i(Sc,T)
Target
C73i(Se,T)
C733
Incoming 2G TCH handover execution radio failures with or without

ROC
C734 Incoming 2G TCH handover for an emergency cause

C735 Incoming 2G TCH handover for a better cell cause
C737 Incoming 2G TCH handover for a traffic cause
Se
C738 Incoming 2G TCH handover for FDR
Sf
1 5 51
C738 Incoming 2G TCH handover with unknown or missing causes

Other counters are provided:
C734(Sx,T): Incoming handovers attempted from Sx to T for an emergency cause.
C735(Sx,T): Incoming handovers attempted from Sx to T for a better cell cause.
C737(Sx,T): Incoming handovers attempted from Sx to T for a traffic cause.
C738(Sx,T): Incoming handovers attempted from Sx to T for a forced directed retry cause.
The set of Type 27 counters can be retrieved for only one cell per BSS at once.

Type 27 Indicators
The following indicators can be computed from PM Type 27 counters in

order to ease the diagnosis of the bad incoming handover performance
of a cell:
Efficiency of the incoming handover execution to cell T from cell Sx
HOIXSUR = C731(Sx,T) / C730(Sx,T)
Rate of incoming ho execution failures due to MS radio access problems to

cell T from cell Sx
HOIXCDRR = C733(Sx,T) / C730(Sx,T)
Rate of incoming ho execution failures due to BSS problems to cell T from cell
Sx
HOIXCDBR= [C730(Sx,T)-C731(Sx,T)-C733(Sx,T)] / C730(Sx,T)
1 5 52


Handover Statistics > HO Statistics per couple of cells > Indicators with counter type 27

1 5 53


Inter-PLMN HO Description
Since B8, outgoing inter-PLMN HO are available (incoming were always

available)
Usage of CGI n the OMC-R allows to define outgoing inter-PLMN adjacencies
(serving cell from own PLMN, target cell from foreign PLMN)
OMC-R
FRANCE
ITALIE
External cells : belong to another

OMC-R (from own PLMN or foreign
PLMN)
Internal cells : belong to this
OMC-R
Up to 4 foreign PLMN's can be
defined in one OMC-R.
Outgoing
Inter-PlMN external cells are

defined by their CGI
Incoming
1 5 54

MCC is the Mobile Country Code, MNC is the Mobile Network Code, LAC is the Location Area Code, CI is the Cell
Identification.
Handovers towards cells belonging to a different PLMN are not possible if CGI_REQD is set to 0.
Handovers towards UMTS cells belonging to a different PLMN are not possible if CGI_3G_REQUIRED is set to 0.
The MS will only measure those Neighbour cells which have a BSIC whose PLMN colour code matches with the
coding in the NCC Permitted transmitted to the MS in the SYSTEM INFORMATION TYPE 6.

B11
Inter-PLMN Indicators
RTCH_HO_Inc_InterPLMN_request
RTCH_HO_Inc_InterPLMN_request_ratio
RTCH_HO_Inc_InterPLMN_allocated
RTCH_HO_Inc_PLMN_fail_cong
B11
RTCH_HO_Inc_InterPLMN_success
RTCH_HO_Out_InterPLMN_request
RTCH_HO_Out_InterPLMN_attempt
RTCH_HO_Out_InterPLMN_success
1 5 55

RTCH_HO_Inc_InterPLMN_request_ratio : RTCH_HO_Inc_InterPLMN_request / RTCH_HO_request

2G-3G Indicators
INCOMING
HO_Inc_MSC_3G_2G_request
HO_Inc_MSC_3G_2G_TCH
request
HO_Inc_MSC_3G_2G_TCH_fail_3Gcong
HO_Inc_MSC_3G_2G_allocated
HO_Inc_MSC_3G_2G_TCH
request_emergency
HO_Inc_MSC_3G_2G_success
HO_Inc_MSC_3G_2G
fail_prep_System
HO_Inc_MSC_3G_2G_HOreject_HL_Time
HO_Inc_MSC_3G_2G_fail_radio
HO_Inc_MSC_3G_2G_fail_BSS
OUTGOING
HO_Out_MSC_2G_3G_required
HO_Out_MSC_2G_3G_request
HO_Out_MSC_2G_3G_prep_fail
HO_Out_MSC_2G_3G_success
HO_Out_MSC_2G_3G_ROC
1 5 56
HO_Out_MSC_2G_3G
failure_radio
HO_Out_MSC_2G_3G
drop_BSS

HO_Inc_MSC_3G_2G_HOreject_HL_Time :
- Cumulative time (in seconds) during which the Cell is in 3G high load state
- i.e. Whenever the 3G_HOReject_Load State in the cell is reported as high or reported as indefinite while the
previous state was high. This counter shall be incremented only if THR_CELL_LOAD_3G_REJECT < 100%.

1 5 57



Indicator
HO cause
distribution
Formulae
Threshold
(MC67w or MC785x or MC586y or MC10zz or MC447 or MC461

(MC67all + MC785all + MC586all + MC10all + MC447 + MC461)
MC67all=MC671+MC672+MC673+MC674+MC675+MC676+MC677+MC6
78+MC679+MC670
MC785all = MC785a + MC785d + MC785e + MC785f (Microcell)
MC586all = MC586a + MC586b + MC586c (concentric)
MC10all = MC1040 + MC1044 + MC1050
Qual DL > 10%

Qual UL > 10%
Level UL > 20%
Level DL > 20%
Interf UL > 5%
Interf DL > 5%
Better Cell < 30%
Com
men
ts
Ref. name
GHCSTBPBR,
GHCCCELVDR,
GHCCCELVUR,
GHCCCBCPR,
GHCSTEDIR,
GHCSTEIFDR,
GHCSTELVDR,
GHCSTEQLDR,
GHCSTBDRR,
GHCMBBCPR,
GHCMCEBSR,
GHCMCELVDR,
GHCMCBCPR,
GHCMCELVUR,
GHCSTEMIR,
GHCSTEIFUR
GHCSTELVUR,
GHCSTEQLUR,
GHCSTAMR,
GHCSTBTFR
HO CAUSE DISTRIBUTION : distribution of HO attemps by cause X : UL/DL Qual, UL/DL Lev,
UL/DL Interference, Distance, Better Cell, Interband, Micro cells HO, Concentric Cell, Traffic, AMRS, TFO
causes
Indicator aiming at measuring the efficiency of planning /optimization
1 5 58


Unit
Handover Standard Cause Distribution

Indicator
Distribution
HO cause
standard
Formulae
Threshold
Com
men
ts
(MC67x) / GLOBAL HO CAUSE STANDARD

MC67x = MC670 or MC672 or MC671 or MC673 or MC676 or
MC677 or MC678 or MC674 or (MC670+MC672) or
(MC671+MC673) or (MC676+M677)
Ref. name
GHCSTEIFDSR,
GHCSTEIFUSR,
GHCSTEIFSR,
GHCSTELVDSR,
GHCSTELVUSR,
GHCSTELVSR,
GHCSTEQLDSR,
GHCSTEQLUSR,
GHCSTEQLSR,
GHCSTBPBSR,
GHCSTEDISR
DISTRIBUTION HO CAUSE STANDARD : Distribution of Handover attempts by

standard cause : Power Budget, quality too low, level too low, high
interference and MS-BTS distance too long.
Indicator aiming at measuring the efficiency of planning / optimization
Interesting for comparing HO distribution after concentric or micro cell
implementation
1 5 59

The Global HO cause standard indicator is defined as below:

where:
MC670: Number of handover attempts cause 2: "uplink quality too low"
MC672: Number of handover attempts cause 4: downlink quality too low"
MC671: Number of handover attempts cause 3: "uplink level too low"
MC673: Number of handover attempts cause 5: "downlink level too low"
MC676: Number of handover attempts cause 15: "too high uplink interference level"
MC677: Number of handover attempts cause 16: "too high downlink interference level"
MC678: Number of handover attempts cause 12: "too low power budget"
MC674: Number of handover attempts cause 6: "MS-BTS distance too long"

Unit
%

HANDOVER
CAUSE rates
1 5 60


Handover statistics INDICATORS > Handover causes
GHCXXYYYYR: Rate of specific HO cause xxyyyy versus all HO causes (Global)
where XX = ST (standard) or MC (micro cell) or CC (concentric cell) or MB (multi band)
and YYYY is specific to the cause

Outgoing Handover Success Rate

Global
success rate of Outgoing HO : Rate of successful outgoing external and internal

intercell SDCCH and TCH HO
Indicator
HO_Out_success_rate
Formulae
HO_Out_success/HO_Out_required
Thres
hold
90%
Comments
This indicator
includes
preparation and
execution.
Ref. name
Unit
GHOORSUR
Success rate of execution of Outgoing HO : Rate of successful outgoing external and

internal intercell SDCCH and TCH HO
Indicator
HO_Out_efficiency_rate
Formulae
HO_Out_success/HO_Out_request
1 5 61
Thres
hold
90%
Comments
Ref. name
Unit
This indicator
takes into account
HO execution only
(not HO
preparation).
GHOOREFR

Global Outgoing HO success rate: represents the global efficiency of the outgoing handovers performed from one cell
to any of its neighboring cells (same BSS or not).
Efficiency of Outgoing HO execution: represents the efficiency of the channel change procedure during outgoing
handovers performed from one cell to any of its neighboring cells (same BSS or not). It does not take into account the
HO failures that can occur during the preparation phase when the new channel is being selected and activated.
HO_Out_success = HO_Out_MSC_2G_3G_success + HO_Out_MSC_2G_2G_success + HO_Out_BSC_success
HO_Out_required = HO_Out_MSC_2G_2G_required+HO_Out_BSC_required+HO_Out_MSC_2G_3G_required
HO_Out_request = HO_Out_MSC_2G_2G_request+HO_Out_BSC_request+HO_Out_MSC_2G_3G_request

Incoming Handover Success Rate

Global
success rate of Incoming HO : Rate of successful incoming external and internal

intercell SDCCH and TCH HO
Indicator
HO_Inc_success_rate
Formulae
HO_Inc_success / HO_Inc_request
Thres
hold
Comments
90%
Ref. name
Unit
GHOIRSUR
Success rate of execution of Incoming HO : Rate of successful incoming external and

internal intercell SDCCH and TCH HO
Indicator
HO_Inc_efficiency_rate
Formulae
HO_Inc_success / HO_Inc_allocated
1 5 62
Thres
hold
90%
Comments
Ref. name
Unit
Excluding
congestion failures
and BSS
preparation
failures from
requests.
GHOIREFR

Global Incoming HO success rate: represents the global efficiency of the incoming handovers performed to one cell
from any of its neighboring cells (same BSS or not).
Efficiency of Incoming HO execution: represents the efficiency of the channel change procedure during incoming
handovers performed to one cell from any of its neighboring cells (same BSS or not). It does not take into account the
HO failures that can occur during the preparation phase when the new channel is being selected and activated.
HO_Inc_success = HO_Inc_MSC_success + HO_Inc_BSC_success
HO_Inc_request = HO_Inc_MSC_request + HO_Inc_BSC_request
HO_Inc_allocated = HO_Inc_MSC_allocated + HO_Inc_BSC_allocated

Handover Failure Main Causes

Main Causes of handover failure
Bad handover parameters settings (check with the RFT Training)

Hardware fault (TRX board fault)
Congestion
Interference
Coverage
Clock or timer mismatching
1 5 63

Coverage
Coverage hole
Coverage hole may exist when coverage areas of two BTSs do not overlap or there are some big obstacles in the
coverage area, this lead to no signal or very poor signal level.
Over shooting
In the actual network, the high BTS antenna can propagate far away along a road and serve in area which its not
suppose to serve in; which result in the "isolate Island" problem.
Interference
Interference usually occurs when more than one idle channel appear in the highest interference band. If the
interference is internal, it will usually increase with the growth of traffic. If the interference is external, it is usually
not related to traffic, but it may increase with the traffic growth if the interference is from the close analog network.
There is also the possibility to work with the RMS (per TRX).
If there are high Rx_lev but bad quality, it indicates that co-channel and/or adjacent-channel interference exist.
Congestion: see previous case study
Timer mismatching: check with the NSS team whether BSS-NSS parameters are well set.

Section 1
Module 6
Directed Retry Indicators
GSM B11

Blank Page
162
B11 GSM QoS Monitoring Directed Retry Indicators

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module Objectives
Describe the counters and indicators used for monitoring the efficiency of the
directed retry feature
163


164


Table of Contents
Page

1 Directed Retry Definition
Queuing Is Mandatory
TCH Assignment with Queuing
Normal and Forced Directed Retry
Directed Retry Rules
Directed Retry During Queuing
2 Queuing and (F)DR Indicators
Queuing
Directed Retry
End of Module
165
7
8
9
10
11
12
13
14
15
16
17



166


167


Queuing Is Mandatory
When there is no TCH available in a cell for TCH normal assignment
Queuing: TCH request is put in a queue, waiting for a TCH to be

released in this cell
With default BSS tuning: the call establishment fails if no TCH has been
freed after T11 seconds
but an optional mechanism can be activated
168

The queuing of TCH requests is also performed for incoming external TCH handovers but not for incoming internal
TCH handovers.
T11 : BSC parameter, Maximum queuing time for Assignment Requests (values : 0 to 19 s; default 6s)

TCH Assignment with Queuing
TCH resource
becomes "free" in the
serving cell
T11
MC13a
169

if the BSC has enough queuing buffers to queue the request or there is a lower priority request that can be
dequeued, BSC puts the request in a queue and starts the queuing timer T11.
Note A: This chart describes the case where the congestion situation ends as a result of a TCH being made
available on the serving BTS. Note that the congestion situation can also be handled by the Directed retry
procedure, in which case the MS is handed over to a Point-to-Point TCH
located on another BTS, see next slides.
Note B: If the queuing is not allowed by the MSC, but QUEUE_ANYWAY = TRUE, no QUEUING INDICATION message
is sent to the MSC
Note C: ATER CONN REQ procedure is done only for TDM BTS in case of BSS transport mode = IP.

Normal and Forced Directed Retry
Directed Retry (DR)

When a TCH request is in queue, the BSC tries to establish the TCH
connection on a neighboring cell if:
the normal handover condition is met (Normal DR)
specific directed retry conditions are met (Forced DR):
the MS receives a sufficient signal level from a neighboring cell
the number of free TCHs in this neighboring cell is sufficient
Normal DR : Should be enabled all the time, to avoid call drop. It just allows a
MS in a queue to perform a standard HO.
Forced DR : Should be enabled to fight congestion. It leads to a radio quality
degradation (MS not in the best serving cell anymore).
1 6 10


Directed Retry Rules

DR FAIL. CASES > DR Reminder
DR as an SDCCH to TCH handover
can be
Internal
between two cells of the same BSC

also called intra BSC
External
Asynchronous
not synchronous for any reason
no dedicated monitoring for
synchronous/asynchronous HO
Incoming
as considering the target cell
Outgoing
as considering the serving cell
1 6 11
ANNEX 3
between 2 cells
sharing the same clocks
collocated
usually 2 sectors of the same BTS
tunable at OMC-R level
between two cells of different

BSCs
also called inter BSC
Synchronous

There is no Intracell Directed Retry contrary to HO:

An Intracell Directed is a Call Setup !! !-)
Please refer to Annexes for Directed Retry counters details.

Directed Retry During Queuing

MC144e/f
Detection of possible DR
with neighbour
MC153
Same message flow

as a Handover
MC717a
MC142e/f
then, SDCCH released in the serving cell
1 6 12

MC144e : outgoing internal DR request

MC144f : outgoing external DR request
MC153 : incoming internal DR request (no counter for incoming external DR)
MC142e : outgoing internal DR success
MC142f : outgoing external DR success
MC717a : incoming internal DR success (no counter for incoming external DR)

End with Assignment Complete

(not "HO Performed")
1 6 13


Queuing
Alc_Mono_Queuing
RTCH queueing failure - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone: Global - Medium)
120.0%
100.0%
Rejected
60.0%
40.0%
80.0%
Timeout
Success
% Success
20.0%
00.0%
16
/0
5/
20
09
17
22
/0
5/
22
20
:0
09
17
0
0
/0
0
5/
0
20
0:
00
09
17
/0
02
5/
02
20
:0
09
17
0
04
/0
5/
04
20
:0
09
17
0
06
/0
5/
0
20
6:
00
09
17
08
/0
5/
08
20
:0
09
17
0
10
/0
5/
10
20
:0
09
17
0
12
/0
5/
12
20
:0
09
17
0
14
/0
5/
14
20
:0
09
17
0
1
/0
6
5/
1
20
6:
00
09
17
18
/0
5/
18
20
:0
09
0
20
20
:0
0
nb
200
180
160
140
120
100
80
60
40
20
0
1 6 14

Rejected : A queued request is rejected because another request is placed in the queue, with a higher priority.
Timeout : The queued request stayed T11 in the queue and is then removed.

Directed Retry
Alc_Mono_DR_Outgoing
Outgoing internal Directed Retry - CELL2G: cell00301_03017 (301/3017) (
999/F77/301/3017 ) - 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone:
Global - Medium)
1400
90.00%
1200
80.00%
Fail BSS
60.00%
Fail Radio
800
50.00%
ROC
600
40.00%
Prep Fail
30.00%
Success
20.00%
% Success
nb
400
200
70.00%
1000
10.00%
1 6 15
17/05/2009 21 21:00
17/05/2009 20 20:00
17/05/2009 19 19:00
17/05/2009 18 18:00
17/05/2009 17 17:00
17/05/2009 16 16:00
17/05/2009 15 15:00
17/05/2009 14 14:00
17/05/2009 13 13:00
17/05/2009 12 12:00
17/05/2009 11 11:00
17/05/2009 10 10:00
17/05/2009 09 09:00
17/05/2009 08 08:00
17/05/2009 07 07:00
17/05/2009 06 06:00
17/05/2009 05 05:00
17/05/2009 04 04:00
17/05/2009 03 03:00
17/05/2009 02 02:00
17/05/2009 01 01:00
17/05/2009 00 00:00
16/05/2009 23 23:00
0.00%
16/05/2009 22 22:00

There is also an indicator (not in this graph) that counts only the number of FDR attempts (DR_forced, GDRFORQN
= MC607)
This indicator can be compared to MC144e/f in order to know the ratio FDR vs. normal DR.


for this module
1 6 16


End of Module
Directed Retry Indicators
1 6 17


Section 1
Module 7
RMS Indicators
GSM B11

Blank Page
172
B11 GSM QoS Monitoring RMS Indicators

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module Objectives
Describe the RMS indicators used for radio quality assessment of a TRX or cell
and to use them in the detection of some typical radio problems
173


174


Table of Contents
1 Radio Measurement Statistics Objectives
RMS Objectives
2 RMS Implementation in the BSS
RMS Management
RMS Configuration in the OMC-R
RMS Configuration in NPO
RMS Data Flow
RMS Data Presentation
3 RMS Data
4 Call Quality Statistics per TRX
4.1 Generalities
4.2 Call Quality Parameters
4.3 Call Quality Counters
5 Radio Quality Statistics per TRX
5.1 Generalities
5.2 Radio Quality Parameters
5.3 Radio Quality Counters
6 C/I Statistics
6.1 C/I Generalities
6.2 C/I Parameters
6.3 C/I Counters
7 RMS Indicators Usage
175
7.1
a Voice Quality Problem
B11 GSMSuspecting
QoS Monitoring RMS Indicators
7.2
Suspecting a Cell Coverage Problem
Exercise 1
Exercise 2
7.3 Suspecting a Cell Interference Problem
Exercise 3
Exercise 4
Exercise 5
8 Additional Information
RMS Counters
End of Module

Page
7
8
10
11
12
13
14
15
16
17
18
19
22
24
28
29
32
35
49
50
51
52
54
55
56
58
59
60
61
62
63
64
65
68
69

Page
176


1 Radio Measurement Statistics

Objectives
177


RMS Objectives
Assess the quality of cell coverage

Assess the radio link quality of a TRX / a cell
Assess Carrier/Interference ratio of a TRX / a cell
Estimate the voice quality of a TRX / a cell
In order to:
Optimize the neighborhood & frequency planning

Improve the network coverage
Detect faulty hardware components responsible for bad QoS
Help logical parameters fine tuning
178

The RMS feature provides statistics on Voice Quality. VQ data are now needed since the Call Drop rate is not
sufficient to have a clear picture of the QoS in a network using Slow Frequency Hopping as a densification
technique.
The RMS feature is a "plus" providing additional information to help radio engineer in their Fault detection and
Network optimization tasks.

RMS Objectives [cont.]
Provide Radio Measurement Statistics

On all the network elements (all TRXs/cells)
Permanently through the PM type 31
RMS results available every day (after a specific period)
In order to reduce the cost of Radio Network Optimization
179

Today's solutions for Radio Measurements are limited and very expensive:
drive tests: provide a mobile user with the perception of the network but cannot be done on the whole
network and on an every day basis since:
they are costly (tool+car+manpower).
they need to be post-processed.
they are limited to part of the network.
they are available on the DownLink path only.
Abis interface traces: provide a complete Uplink and Downlink radio quality assessment of a cell but cannot be
done on the whole network and on an every day basis since:
they are costly (protocol analyzer+manpower).
they need to be post-processed.
they are limited to a few cells at once per analyzer.

1 7 10


RMS Management
RMS results are reported permanently (once a day) by the BSS as a PM

Type 31 counters to the OMC-R
The RMS job is defined and activated on a per BSS basis
RMS job parameters are managed through RMS templates

RMS templates provide means to tune RMS parameters according to Cell
Planning (cell profile, cell class)
1 7 11

The cell profile can be: micro, indoor, multiband, etc.

The cell class can be: rural, urban, rural rapid (covering express railway), etc.
Templates parameters define the intervals or Received level, Consecutive frame erasure, Radio link counter,
Path balance, C/I for which RMS counters are provided.

RMS Configuration in the OMC-R
RMS with OMC-R only

Templates are defined on the
OMC-R
RMS results are retrieved once
a day from the BSC
Binary files can be exported for
post-processing
Templates
Templates
RMS in binary files
PM
1 7 12


B11
RMS Configuration in NPO
RMS with OMC-R

& NPO
Templates are
defined on NPO
RMS results are
retrieved once a day
from the BSC
Binary files are
transferred to NPO
RMS warnings on NPO
RMS QoS reports on
NPO
RMS reports used in
NPO
Check
QoS follow-up
Diagnosis
Tuning
Templates
A9159 NPO
Software application
PM
1 7 13

The cell profile can be: micro, indoor, multiband, etc.

The cell class can be: rural, urban, rural rapid (covering express railway), etc.

B11
RMS Data Flow

1.
2.
3.
4.
5.
NPO defines and sends

RMS templates to the
OMC-R
The OMC-R activates an
RMS campaign in the BSS
RMS counters are
transferred to
the OMC
RMS counters are stored
in NPO
RMS QOS report displayed
BSS
3
PM
PM
OMC-R
1
5
Template
NPO
QOS
1 7 14

The tuning function of NPO defines a preferred RMS template depending on cell characteristics (type, class,
capacity, etc.).
NPO manages the frequencies to monitor through MAFA jobs depending on the neighborhood and the frequency
bands.
NPO is a reference for RMS templates:
16 templates stored in the NPO database,
Reference values for templates available,
Extra editor in the administration tool to modify templates: a given value or a reference one.
NPO stores RMS jobs measurements, at Cell & TRX levels (15 days).
NPO makes some consolidations (voice quality, averages, etc.).
NPO manages some warnings on RMS indicators (path balance).

In all this chapter

System parameters (user tuneable or not) will always be written in BLUE
BOLD FONT
Indicators and counters will be typed
in ITALIC and underline
1 7 15


3 RMS Data
1 7 16


3 RMS Data
The main RMS statistics types:

Call Quality Statistics which qualify calls according to coverage/interference
criteria
based on samples corresponding to measurement results averaged over a number of
SACCH multi-frames
Radio Quality Statistics:
UL/DL level, UL/DL qual

CFE
AMR (Analyze the coded values)
Timing Advance
C/I Statistics on neighboring freq/MAFA freq

last 2 statistics types based on samples corresponding to measurement results
Annex 1
1 7 17

The first RMS Statistics type is based on calls.

The two others are based on TRX/Cell.
Additional information: Measurement results, TRX, BS/MS max power
MAFA = Mobile Assisted Frequency Allocation is a GSM Phase 2+ feature allowing to request a mobile to measure
and report through Extended Measurement Report message a C/I value for each frequency specified in an
Extended Measurement Order message.
CFE: Consecutive Frame Erasure
1 SACCH multi-frame (SACCH mfr) corresponds to 4 consecutive sequences of 26 TDMA frames during which, in
the uplink, a measurement report message is received by the BTS from the MS.

1 7 18


4.1 Generalities
Suspecting a Voice Quality problem

Percentage of Noisy calls
1 7 19

The fact that FER measurements are more reliable than RXQUAL ones to assess the VQ is even more true when
using Slow Frequency Hopping. In this case RXQUAL values are not anymore correlated to Voice Quality as
perceived by the end user.
FER measurements are available for the uplink path only.
These RMS indicators are provided on the NPO tool per TRX, per Cell:
Number of Noisy calls suffering from problem of bad coverage on the uplink path
RMVQULVN = RMS_call_noisy_UL_bad_coverage
Number of Noisy calls suffering from problem of interference on the uplink path
RMVQUIFN = RMS_call_noisy_UL_interference
Number of Noisy calls suffering from problem of interference and bad coverage considered together on the
uplink path
RMVQUUKN = RMS_call_noisy_UL_undefined
Rate of Noisy calls suffering from problems of interference or/and bad coverage on the uplink path
RMVQUNOR = RMS_call_noisy_UL_rate
Note: The 4 indicators above can be provided for Noisy calls suffering from VQ problems on the downlink path.
Rate of Noisy calls but with good FER measurements on the uplink path
RMVQFEGR = RMS_call_noisy_good_FER_rate
Rate of Noisy calls and also with bad FER measurements on the uplink path
RMVQFEBR = RMS_call_noisy_bad_FER_rate
Rate of calls with fair quality measurements but with bad FER measurements on the uplink path
RMVQFEAR = RMS_call_abnormal_bad_FER_rate
This last indicator can be used in order to tune the RMS VQ parameters used to characterize a call as Noisy.

4.1 Generalities [cont.]
Call Quality Measurements
SACCH meas.
begin
CQS1
CQS2
CALL
end
480ms
CQS3
CQS4 CQS5
CQS6
CQS7
CQS8
CQS9 CQS10 CQS11 CQS12 CQS13 CQS14 CQS15 CQS16
CQS375
1 measurement report
1 SACCH mfr
VQ_AVERAGE = 4 SACCH
AV_RXLEV_UL_VQ = (RxlevUL1+RxlevUL2+RxlevUL3+RxlevUL4) / 4
AV_RXLEV_DL_VQ = (RxlevDL1+RxlevDL2+RxlevDL3+RxlevDL4) / 4
AV_RXQUAL_UL_VQ = (RxqualUL1+RxqualUL2+RxqualUL3+RxqualUL4) / 4
AV_RXQUAL_DL_VQ = (RxqualDL1+RxqualDL2+RxqualDL3+RxqualDL4) / 4
AV_RXFER_UL_VQ = (Nb of speech frames wrongly decoded (BFI=1)
/ Total nb of speech frames of the CQS)
Average level, quality and FER of a Call Quality Sample

1 7 20

CQS: Call Quality Sample

VQ_AVERAGE = Number of consecutive SACCH measurements from which the reported Level and Quality notes (UL
and DL) are averaged. The resulting averages represent the level and quality of the corresponding Call Quality
Sample, i.e. the portion of the call over which level and quality have been measured.
AV_RXLEV_xx_VQ = Average xx level measured over a Call Quality Sample (VQ_AVERAGE SACCH)
AV_RXQUAL_xx_VQ = Average xx quality measured over a Call Quality Sample (VQ_AVERAGE SACCH)

Classification of a CQS and Noisy Call identification

How to qualify the quality of a call? By looking at the repartition of the CQS!
quality
7
bad quality & level
bad coverage CQS
bad quality + good level
interfered CQS
CQS
VQ_RXQUAL
Level (dBm)
0
-110
VQ_RXLEV
1 7 21
-47

VQ_RXLEV = radio level threshold to classify a CQS as bad coverage CQS.

VQ_RXQUAL = radio quality threshold to classify a CQS as bad coverage CQS.
VQ_INTF_THRESHOLD = Ratio of bad CQS (interference or bad coverage) to classify a Call as Noisy.
A call is classified as:
Noisy xx Interference if Ratio of xx interfered CQS > VQ_INTF_THRESHOLD
Noisy xx Coverage if Ratio of xx bad coverage CQS > VQ_INTF_THRESHOLD
Noisy xx Undefined if Ratio of (xx interfered CQS + xx bad coverage CQS) > VQ_INTF_THRESHOLD

4.2 Call Quality Parameters
RMS parameters: Call Quality Statistics

Parameters used to determine if a call is noisy (according to RXQUAL)
and of bad voice quality (according to FER)
VQ_AVERAGE: averaging window size on measurement results to obtain Call
Quality Samples (CQSs) (0 SACCH mfr to 128 Smf)
VQ_RXLEV: radio level threshold to specify a bad coverage CQS for noisy call
statistics (-110 to -65 dBm)
VQ_RXQUAL: radio quality threshold to specify a bad quality (RXQUAL) CQS
for noisy call statistics (0 to 7)
VQ_RXQUAL_VS_RXFER: radio quality threshold to specify a bad or a good
quality CQS correlated to bad or good FER measurements for noisy call
statistics (0 to 7)
1 7 22

All these parameters are included in the RMS PM Type 31 result files as RMS counters:
RMSpc = PAR_VQ_AVERAGE
RMSpd = PAR_VQ_RXLEV
RMSpe = PAR_VQ_RXQUAL
RMSpf = PAR_VQ_RXQUAL_VS_RXFER
Call Quality Sample (A CQS) will be qualified as of bad level if the Average RxLevel is lower than VQ_RXLEV.
A CQS will be qualified as of bad quality if the Average RxQuality is greater than VQ_RXQUAL.
For FER counters, VQ_RXQUAL_VS_RXFER is used instead of VQ_RXQUAL to qualify a CQS as of bad quality if the
Average FER is also checked (compared to VQ_xx_RXFER).
Note: For CQS, the averaging process is non-sliding.

4.2 Call Quality Parameters [cont.]
RMS parameters: Call Quality Statistics

VQ_GOOD_RXFER: Frame Erasure Rate threshold to specify a good FER CQS
for noisy call statistics (0 to 20%)
VQ_BAD_RXFER: FER threshold to specify a bad FER CQS for noisy call
statistics (0 to 20%)
VQ_INTF_THRESHOLD: Call Quality Samples threshold to characterize a call
as noisy (0 to 100%)
VQ_FER_THRESHOLD: Call Quality Samples threshold to characterize a call
as of bad or good voice quality (0 to 100%)
1 7 23

RMSpg = PAR_VQ_GOOD_RXFER
RMSph = PAR_VQ_ BAD_RXFER
RMSpi = PAR_VQ_INTF_THRESHOLD
RMSpj = PAR_VQ_FER_THRESHOLD

4.3 Call Quality Counters
RMS counters
VQ_NOISY_UL_INTERFERENCE = RMS10
Number of calls suffering from interference problem on the uplink path
VQ_NOISY_UL_INTERFERENCE is incremented whenever a call verifies:
100*(INTERFERED_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD
with
INTERFERED_UL_SAMPLES = nb of times where AV_RXQUAL_UL_VQ > VQ_RXQUAL
and AV_RXLEV_UL_VQ>VQ_RXLEV
1 7 24

Call Quality Statistics counters are related only to speech channels.

Considering:
AV_RXQUAL_UL_VQ: average on VQ_AVERAGE measurements of RXQUAL_UL
AV_RXLEV_UL_VQ: average on VQ_AVERAGE measurements of RXLEV_UL
NUM_UL_SAMPLES: total number of averages calculated on UL measurements during the call on the considered
TRX

4.3 Call Quality Counters [cont.]
RMS counters
VQ_NOISY_UL_INTERFERENCE = RMS10
Number of calls suffering from interference problem on the uplink path
VQ_NOISY_DL_INTERFERENCE = RMS11
Number of calls suffering from interference problem on the downlink path
VQ_NOISY_UL_COVERAGE = RMS12
Number of calls suffering from bad coverage problem on the uplink path
VQ_NOISY_DL_COVERAGE = RMS13
Number of calls suffering from bad coverage problem on the downlink path
1 7 25

RMS10 = VQ_NOISY_UL_INTERFERENCE is incremented whenever a call verifies:

100*(INTERFERED_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD
with
INTERFERED_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL
and AV_RXLEV_UL_VQ>VQ_RXLEV
considering
AV_RXQUAL_UL_VQ: average on VQ_AVERAGE measurements of RXQUAL_UL
AV_RXLEV_UL_VQ: average on VQ_AVERAGE measurements of RXLEV_UL
NUM_UL_SAMPLES: total number of averages calculated on UL measurements during the call on the considered TRX
RMS11 = VQ_NOISY_DL_INTERFERENCE is incremented whenever a call verifies: 100*(INTERFERED_DL_SAMPLES /
NUM_DL_SAMPLES) > VQ_INTF_THRESHOLD
with
INTERFERED_DL_SAMPLES = nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL
and AV_RXLEV_DL_VQ>VQ_RXLEV
considering
AV_RXQUAL_DL_VQ: average on VQ_AVERAGE measurements of RXQUAL_DL
AV_RXLEV_DL_VQ: average on VQ_AVERAGE measurements of RXLEV_DL
NUM_DL_SAMPLES: total number of averages calculated on DL measurements during the call on the considered TRX
RMS12 = VQ_NOISY_UL_COVERAGE is incremented whenever a call verifies: 100*(BAD_COVERAGE_UL_SAMPLES /
NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD
with BAD_COVERAGE_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL and AV_RXLEV_UL_VQ<=VQ_RXLEV
RMS13 = VQ_NOISY_DL_COVERAGE is incremented whenever a call verifies: 100*(BAD_COVERAGE_DL_SAMPLES /
NUM_DL_SAMPLES) > VQ_INTF_THRESHOLD
with BAD_COVERAGE_DL_SAMPLES = nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL and AV_RXLEV_DL_VQ<=VQ_RXLEV

RMS counters
VQ_NOISY_UL_UNDEFINED = RMS14
Number of calls suffering from both problems of interference and bad
coverage on the uplink path
These calls are not counted in VQ_NOISY_UL_COVERAGE or
VQ_NOISY_UL_INTERFERENCE
VQ_NOISY_DL_UNDEFINED = RMS15
Number of calls suffering from both problems of interference and bad
coverage on the downlink path
These calls are not counted in VQ_NOISY_DL_COVERAGE or
VQ_NOISY_DL_INTERFERENCE
1 7 26

RMS14 = VQ_NOISY_UL_UNDEFINED is incremented whenever a call verifies:

100*(BAD_COVERAGE_UL_SAMPLES / NUM_UL_SAMPLES) <= VQ_INTF_THRESHOLD
and 100*(INTERFERED_UL_SAMPLES / NUM_UL_SAMPLES) <= VQ_INTF_THRESHOLD
and 100*(BAD_QUALITY_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD
with
BAD_COVERAGE_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL and
AV_RXLEV_UL_VQ<=VQ_RXLEV
INTERFERED_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL
and AV_RXLEV_UL_VQ > VQ_RXLEV
BAD_QUALITY_UL_SAMPLES = INTERFERED_UL_SAMPLES + BAD_COVERAGE_UL_SAMPLES
= nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL
RMS15 = VQ_NOISY_DL_UNDEFINED is incremented whenever a call verifies:
100*(BAD_COVERAGE_DL_SAMPLES / NUM_DL_SAMPLES) <= VQ_INTF_THRESHOLD
and 100*(INTERFERED_DL_SAMPLES / NUM_DL_SAMPLES) <= VQ_INTF_THRESHOLD
and 100*(BAD_QUALITY_DL_SAMPLES / NUM_DL_SAMPLES) > VQ_INTF_THRESHOLD
with
BAD_COVERAGE_DL_SAMPLES = nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL
and AV_RXLEV_DL_VQ<=VQ_RXLEV
INTERFERED_DL_SAMPLES = nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL
and AV_RXLEV_DL_VQ > VQ_RXLEV
BAD_QUALITY_DL_SAMPLES = INTERFERED_DL_SAMPLES + BAD_COVERAGE_DL_SAMPLES
= nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL

RMS counters
VQ_NOISY_UL_BAD_FER = RMS16
Number of calls with bad quality measurements and with bad FER
measurements on the uplink path
Bad quality means bad RXQUAL whatever RXLEV is
VQ_NOISY_UL_GOOD_FER = RMS17
Number of calls with bad quality measurements but with good FER
VQ_ABNORMAL_BAD_FER = RMS18
Number of calls with fair quality measurements but with bad FER
1 7 27

RMS16 = VQ_NOISY_UL_BAD_FER is incremented whenever a call verifies:

100*(BAD_QUALITY_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD
and 100*(BAD_QUAL_BAD_FER_UL_SAMPLES / BAD_QUALITY_UL_SAMPLES) > VQ_FER_THRESHOLD
with
BAD_QUAL_BAD_FER_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL_VS_RXFER and
AV_RXFER_UL_VQ > VQ_BAD_RXFER
considering
AV_RXFER_UL_VQ: average on VQ_AVERAGE measurements of FER
RMS17 = VQ_NOISY_UL_GOOD_FER is incremented whenever a call verifies:
100*(BAD_QUALITY_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD
and 100*(BAD_QUAL_GOOD_FER_UL_SAMPLES / BAD_QUALITY_UL_SAMPLES) > VQ_FER_THRESHOLD
with
BAD_QUAL_GOOD_FER_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL_VS_RXFER and
AV_RXFER_UL_VQ <= VQ_GOOD_RXFER
RMS18 = VQ_ABNORMAL_BAD_FER is incremented whenever a call verifies:
100*(FAIR_QUAL_BAD_FER_UL_SAMPLES / FAIR_QUALITY_UL_SAMPLES) > VQ_FER_THRESHOLD
with
FAIR_QUALITY_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ < VQ_RXQUAL_VS_RXFER
FAIR_QUAL_BAD_FER_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ<VQ_RXQUAL_VS_RXFER and
AV_RXFER_UL_VQ>VQ_BAD_RXFER
1 7 28


5.1 Generalities
Suspecting a TRX hardware problem

Average path balance
1 7 29

Vector of the Number of Measurement Results per Path Balance band

RMPBV = RMS_PathBalance_sample
Average Path Balance value

RMPBAN = RMS_PathBalance_avg
A Templates modification is needed to have more details.

Report : MONO_OBJECT_DISTRIBUTION
Alc_Mono_Radio_Link_detailed

Vector Counter
RMS7a=TPR_PATH_BALANCE
RMS7b=MAX_PATH_BALANCE
The real number of Measurement Results in which Path balance is in

PATH BALANCE band j is equal to:
S(PATH BALANCE band j) x Max / 254
TPR_PATH_BALANCE(j) x MAX_PATH_BALANCE / 254
1 7 30

The vector counter system is used to provide:
Path balance repartition
Radio Link counter (Consecutive Frame Erasure) repartition
C/I repartition
AMR FR/HR/DL/UL usage repartition
TA repartition (improved)


TPR_RXQUAL_UL_RXLEV_UL
1 7 31
TMR_RXQUAL_UL_RXLEV_UL

This counter RMS3a=TPR_RXQUAL_UL_RXLEV_UL is a matrix (represented on the left side).

This counter RMS3b=TMR_RXQUAL_UL_RXLEV_UL is a vector (represented on the right side).
The real number of Measurement Results in which UL RxQual is equal to i and UL RxLev is in RXLEV band j, is
equal to:
S(RXQUAL i, RXLEV band j) x Max j / 254
TPR_RXQUAL_UL_RXLEV_UL(i,j) x TMR_RXQUAL_UL_RXLEV_UL(j) / 254

5.2 Radio Quality Parameters
RMS Parameters
Parameters used to define intervals for RXLEV, Path Balance, Radio Link
Counter and Consecutive Frame Erasure, TA statistics
No parameters needed for AMR measurements (counters, see later)
MEAS_STAT_LEV1 to MEAS_STAT_LEV9:
9 thresholds on the received radio level value defining 10 RXLEV bands
-110 MEAS_STAT_LEV(i+1) MEAS_STAT_LEV(i) < -47 dBm
MEAS_STAT_PATH_BAL1 to MEAS_STAT_PATH_BAL9:
9 thresholds on the radio signal propagation loss difference between UL and
DL defining 10 Path Balance bands
-110< MEAS_STAT_PATHBAL(i) MEAS_STAT_PATHBAL(i+1) +110 dB
1 7 32

RMSpt5 = TAB_PAR_MEAS_LEV = Table of 9 parameters MEAS_STAT_LEVi
RMSpt4 = TAB_PAR_MEAS_PATH_BALANCE = Table of 9 parameters MEAS_STAT_PATH_BALi
The Path Balance is computed by the BTS from each Measurement Result message as the difference between:
Path loss on the uplink: received level by the BTS - MS power level
Path loss on the downlink: received level by the MS - BS power level
where the BTS power level is computed as the BTS nominal power minus by the BTS power relative level.
Therefore the Path balance is computed as follows:
Path Balance = (RXLEV_UL - MS_TXPWR) - (RXLEV_DL - [BTS_MAX_OUTPUT_POWER - abs(BS_TXPWR)])
where
RXLEV_UL is the received signal levels measured by the BTS on the uplink path (in dBm).
MS_TXPWR is the MS transmitted power converted by the BTS from the MS power level into dBm
value according to the frequency band of the TRX.
BS_TXPWR is the BTS transmitted power offset defined relatively to the maximum absolute output
power of the BTS (negative value in dB).
BTS_MAX_OUTPUT_POWER is the maximum power of the BTS after Combiner (in dBm).
RXLEV_DL is the received signal levels measured by the MS on the downlink path (in dBm).
NOTE: Additional asymetric DL loss (external combiner) or UL gain (TMA) are not taken into account in the
computation, so they must be considered when interpreting the RMS results.

5.2 Radio Quality Parameters [cont.]
RMS Parameters
TA_STAT: threshold on the timing advance value defining a priori the range
of the cell (0 to 64 bits)
MEAS_STAT_TA1 to MEAS_STAT_ TA9:
9 thresholds for the timing advance to define 10 TA Bands
MEAS_STAT_S1 to MEAS_STAT_S9:
9 thresholds on the BTS Radio Link Counter S value defining 10 S bands
0
< MEAS_STAT_S(i) MEAS_STAT_S(i+1) 128 SACCH mfr

S: counter managed by the BTS on a per call basis
S = RADIOLINK_TIMEOUT_BS if good radio conditions
S decremented if bad radio conditions
The BSS triggers a call drop when S = 0
1 7 33

RMSpt3 = TAB_PAR_MEAS_STAT_S = Table of 9 parameters MEAS_STAT_Si
RMSpb = PAR_TA_STAT
RMSpt6 = TAB_PAR_MEAS_STAT_TA = Table of value for 9 parameters: MEAS_STAT_TA1 to TA9

a threshold on Timing Advance measurement to define bands used for RMS
Reminder on the Uplink Radio Link Supervision procedure:
For each active dedicated radio channel in a cell, a counter S called Radio Link Counter is:
incremented by 2 by the BTS each time a valid SACCH measurement is received from the mobile
(SACCH_BFI=0).
Initial value of S = RADIOLINK_TIMEOUT_BS (cell parameter)
decremented by 1 by the BTS each time an SACCH measurement from the mobile cannot be decoded
(SACCH_BFI=1).
if S reaches N_BSTXPWR_M, a radio link recovery is triggered (BTS and MS power increased at their
maximum).
if S reaches 0, a Radio Link Failure is triggered (channel drop).
Therefore the value of S gives a measure of the quality of the radio uplink.

5.2 Radio Quality Parameters [cont.]
RMS Parameters
MEAS_STAT_BFI1 to MEAS_STAT_BFI9:
9 thresholds on the number of consecutive speech frames with BFI set to 1
defining 10 BFI bands
0 < MEAS_STAT_BFI(i) MEAS_STAT_BFI(i+1) 25 speech frame
The BTS decodes 24 speech frames (sf) from 1 uplink SACCH multi-frame:
and 1 SACCH frame (or block)
SACCH mfr
TDMA: 4,616ms
T T T T T T T T T T T T
C C C C C C C C C C C C
H H H H H H H H H H H H
Sf 1
Sf 2
Sf 3
S
A
C
C
H
Sf 4
Sf 5
Sf 6
Sf 7
Sf 8
Sf 9
1 7 34
S
A
C
C
H
Sf 10
Sf 13 Sf 14
Sf 11
Sf 12
Sf 15
S
A
C
C
H
Sf 16
Sf 19 Sf 20
Sf 17
Sf 18
Sf 21
S
A
C
C
H
Sf 22
Sf 23
Sf 24

RMSpt2 = TAB_PAR_MEAS_STAT_BFI = Table of 9 parameters MEAS_STAT_BFIi
Consecutive Frame Erasure (CFE)
MEAS_STAT_BFIi parameters define 9 intervals of cumulated numbers of consecutive speech frames which have a
Bad Frame Indicator value set to 1 (it means that the speech frame is considered as erroneous by the BTS).
As the TC will erase speech frames for which a Bad Frame Indicator flag (BFI) has been set to the value 1 by the
BTS, a BFI is used in the RMS counters description whereas the CFE is used in the RMS indicators defined in the
NPO tool.
Note: By default, a BFI relates to a speech frame. When considering SACCH measurement, SACCH_BFI should be
used.

5.3 Radio Quality Counters
RMS Counters
Radio Quality Statistics
TPR_RXQUAL_UL_RXLEV_UL: matrix of 8x10 elements UL(RXQUAL i, RXLEV
band j), each element is made up of:
Samplesij: norm of number of measurement result samples in which UL RxQual is
equal to i and UL RxLev is reported in RXLEV band j
MS PWR levelij: average value of MS power (in dBm) from pwr levels reported in
these samples
Timing Advanceij: average value of TAs reported in these samples
TMR_RXQUAL_UL_RXLEV_UL: vector of 10 elements ULRXQUAL(RXLEV band

j), each element is made up of:
the maximum value of the 8 real numbers of samples in which UL RxQual is equal to i
(i=0 to 7) and UL RxLev is reported in RXLEV band j
1 7 35

RMS3a=TPR_RXQUAL_UL_RXLEV_UL
RMS3b=TMR_RXQUAL_UL_RXLEV_UL
The real number of Measurement Results in which UL RxQual is equal to i and UL RxLev is in
RXLEV band j, is equal to:
TPR_RXQUAL_UL_RXLEV_UL(i,j) x TMR_RXQUAL_UL_RXLEV_UL(j) / 254
5.3 Radio Quality Counters [cont.]
RMS Counters
TPR_RXQUAL_DL_RXLEV_DL: matrix of 8x10 elements DL(RXQUAL i, RXLEV
band j), each element is made up of:
Samplesij: norm of number of measurement result samples in which DL RxQual is
equal to i and DL RxLev is reported in RXLEV band j
BS PWR levelij: average value of BS power (in dBm) from pwr levels reported in these
samples
Timing Advanceij: average value of TAs reported in these samples
TMR_RXQUAL_DL_RXLEV_DL: vector of 10 elements DLRXQUAL(RXLEV band j),

each element is made up of:
the maximum value of the 8 real numbers of samples in which DL RxQual is equal to i
(i=0 to 7) and DL RxLev is reported in RXLEV band j
1 7 36

RMS4a=TPR_RXQUAL_DL_RXLEV_DL
RMS4b=TMR_RXQUAL_DL_RXLEV_DL
The real number of Measurement Results in which DL RxQual is equal to i and DL RxLev is in
RXLEV band j, is equal to:
TPR_RXQUAL_DL_RXLEV_DL(i,j) x TMR_RXQUAL_DL_RXLEV_DL(j) / 254
RMS Counters
TPR_PATH_BALANCE: vector of 10 elements UL/DL(PATH BALANCE band j),
each element is made up of:
the norm of number of measurement result samples for which the computed Path
Balance is in PATH BALANCE band j
MAX_PATH_BALANCE:
the maximum value of the 10 real numbers of samples for which the computed Path
Balance is in PATH BALANCE band j (j=1 to 10)
1 7 37

RMS7a=TPR_PATH_BALANCE
RMS7b=MAX_PATH_BALANCE
The real number of Measurement Results in which Path balance is in PATH BALANCE band j,
is equal to:
S(PATH BALANCE band j) x Max / 254
TPR_PATH_BALANCE(j) x MAX_PATH_BALANCE / 254

RMS Counters
TPR_RADIO_LINK: vector of 10 elements UL(S band j), each element is made
up of:
the norm of number of measurement result samples for which the Uplink Radio Link
Counter is in S band j
MAX_RADIO_LINK:
the maximum value of the 10 real numbers of samples for which the Uplink Radio
Link Counter is in S band j (j=1 to 10)
1 7 38

RMS6a=TPR_RADIO_LINK
RMS6b=MAX_RADIO_LINK
The real number of Measurement Results in which Uplink Radio Link Counter is in S band
j, is equal to:
S(S band j) x Max / 254
TPR_RADIO_LINK(j) x MAX_RADIO_LINK / 254

RMS Counters
TPR_BFI_RXLEV_UL: matrix of 10x10 elements UL(BFI i, RXLEV band j), each
element is made up of:
the norm of number of SACCH multi-frames in which the number of consecutive
speech frames with BFIs set to 1 is in BFI band i and UL RxLev reported in the
corresponding measurement results is in RXLEV band j
TMR_BFI_RXLEV_UL: vector of 10 elements ULBFI(RXLEV band j), each

element is made up of:
the maximum value of the 10 real numbers of SACCH multi-frames in which the
number of consecutive speech frames with BFIs set to 1 is in BFI band i (i=0 to 9) and
UL RxLev reported in the corresponding measurement results is in RXLEV band j
1 7 39

RMS5a=TPR_BFI_RXLEV_UL
RMS5b= TPM_BFI_RXLEV_UL
The real number of Measurement Results in which the number of consecutive speech frames with
BFIs set to 1 is in BFI band i and UL RxLev is in RXLEV band j, is equal to:
S(BFI i, RXLEV band j) x Max j / 254
TPR_BFI_RXLEV_UL(i,j) x TMR_BFI_RXLEV_UL(j) / 254
RMS Counters
The BTS increments the BFI (or CFE) counter as soon as consecutive
speech frames cannot be decoded
isolated speech frames with BFIs set to 1 are not counted
sequences of not decoded speech frames are cumulated
SACCH mfr
0
Sf 1 Sf 2
Sf 3 Sf 4 Sf 5 Sf 6
BFI
1
Sf 7 Sf 8 Sf 9 Sf 10 Sf 11 Sf 12 Sf 13 Sf 14 Sf 15 Sf 16 Sf 17 Sf 18 Sf 19 Sf 20 Sf 21 Sf 22 Sf 23 Sf 24 SACCH f.
CFE
0
10
RxLev UL
10
11
12
12
11
11
Av_RxLev_UL= - 110 + INT[(10+11+9+12+12+11+11+10+3+2+0+8+9+5+3+7+2+1+2+7+3+8+2+3+5)/25]

= -104 dBm
1 7 40

RMS Counters for AMR Monitoring

To provide a better tool to dimension the AMR thresholds, B9
introduces a new set of RMS counters to verify the use of different
speech codecs: For Full Rate and Uplink:
AMR_FR_UL_BAD= RMS44a that has 8 cells (1 for each FR codec) with the
relative number of bad speech frames received in uplink.
MAX_AMR_FR_UL_BAD= RMS44b that indicates the maximum number of bad
speech frames received in uplink in one FR codec.
AMR FR codec used in uplink (TRX based)
1 7 41


AMR thresholds; different speech codecs:
For Half Rate and Uplink:
AMR_HR_UL_BAD= RMS45a that has 8 cells (1 for each HR codec) with the
relative number of bad speech frames received in uplink.
MAX_AMR_HR_UL_BAD= RMS45b that indicates the maximum number of bad
speech frames received in uplink in one HR codec.
AMR HR codec used in uplink (TRX based)
1 7 42


AMR Table; different speech codecs:
For Full Rate, UL & DL
AMR_FR_UL_RXLEV_UL= RMS46a that has a table (8x10) with relative number
of correct speech frames received in uplink in each AMR FR codec (8 codecs)
and each level band (10 level bands).
MAX_AMR_FR_UL_RXLEV_UL= RMS46b that has the 10 maximum results. Each
cell Ci of the table indicates the greatest value of the Vik for a i given in
RMS46a.
AMR_FR_DL_RXLEV_DL= RMS47a that has a table (8x10) with relative number
of correct speech frames received in downlink in each AMR FR codec (8
codecs) and each level band (10 level bands).
MAX_AMR_FR_DL_RXLEV_DL= RMS47b that has a table of 10 maximum results.
Each cell Ci of the table indicates the greatest value of the Vik for a i given in
RMS47a.
1 7 43

AMR-FR codec usage compared to RXLEV
RXLEV UL bands are defined as follows:


AMR Table; different speech codecs:
For Half Rate, UL & DL
AMR_HR_UL_RXLEV_UL= RMS48a that has a table (5x10) with relative number
of correct speech frames received in uplink in each AMR HR codec (5 codecs)
and each level band (10 level bands).
MAX_AMR_HR_UL_RXLEV_UL= RMS48b that has a table of 10 maximum
results. Each cell Ci of the table indicates the greatest value of the Vik for a i
given in RMS48a.
AMR_HR_DL_RXLEV_DL= RMS49a that has a table (5x10) with relative number
of correct speech frames received in downlink in each AMR HR codec (5
codecs) and each level band (10 level bands).
MAX_AMR_HR_DL_RXLEV_DL= RMS49b that has a table of 10 maximum
results. Each cell Ci of the table indicates the greatest value of the Vik for a i
given in RMS49a.
1 7 44

AMR-HR codec usage compared to RXLEV
RXLEV UL bands are defined as follows:

RMS Counters for Timing Advance

PERC_TA_GT_TA_STAT:
percentage of measurement results reported with a Timing Advance value > TA_STAT
parameter
MAX_TA:
maximum value of Timing Advance among all TA values reported in the measurement
results used for RMS
1 7 45

Corresponding RMS counter numbers:
RMS36 = PERC_TA_GT_TA_STAT
RMS37 = MAX_TA


A new set of RMS counters related with timing advance analysis.
TRX Based. (Rxlev for UL and DL)
TPR_TIMING_ADVANCE= RMS50a that has 10 cells (1 for each timing advance
band) with relative number of measurements in each Timing advance band.
MAX_TIMING_ADVANCE = RMS50b that has the greatest number of
measurements in one Timing advance band.
TPR_UL_RXLEV_TA_BAND= RMS51 that has 10 cells (1 for each timing advance
band) with average of uplink rxlev in corresponding timing advance band.
TPR_DL_RXLEV_TA_BAND= RMS52 that has 10 cells (1 for each timing advance
band) with average of downlink rxlev in corresponding timing advance band.
1 7 46

The distribution of number of measurement reports for which the value of timing advance is in TA band X is
described below:
There are 10 TA bands which are defined through 9 thresholds parameters, tunable on a cell basis, using the
RMS_parameters_template:
TA band 1 is defined by:
TA band 2 is defined by:
0 <= TA < Meas_STAT_TA_1

MEAS_STAT_TA_1 <= TA < MEAS_STAT_TA_2
TA band 10 is defined by: MEAS_STAT_TA_9 <= TA < 63
The TRE counts for each TA band the number of measurement results, N1 to N10. To save on the memory
resources, these counters are sent to the BSC in a coded format.


A new set of RMS counters related with timing advance analysis.
Uplink:
TPR_UL_RXQUAL_TA_BAND= RMS53: Table of 10 results
that has 10 cells (1 for each timing advance band) with average of uplink
rxqual in corresponding timing advance band.
Downlink:
TPR_DL_RXQUAL_TA_BAND= RMS54 Table of 10 results
that has 10 cells (1 for each timing advance band) with average of uplink
rxqual in corresponding timing advance band.
1 7 47

TPR_UL_RXQUAL_TA_BAND= RMS53
Table of 10 results; Each cell (i) of the table contains the average value of UpLink Rxqual of reports in TA band i.
Averaged Rxqual is given with a precision of 2 digits after the comma (step size for coding = 0.01, 0 coded 0, 0.01
coded 1, ...).
i = 1...10
TA band i is defined by MEAS_STAT_TA_ (i-1)<= Timing Advance < MEAS_STAT_TA_i
MEAS_STAT_TA_0 = 0 bper, MEAS_STAT_LEV_10 = 63 bper.
TPR_DL_RXQUAL_TA_BAND= RMS54
Table of 10 results (same for Downlink).


MAX_POWER_PER_TRX
Maximum GMSK TRX power level applied at the BTS antenna output
connector in dBm.
The power takes into account the different losses
(cables, internal combiners)
TRX Based
1 7 48

MAX_POWER_PER_TRX= RMSPw3
Maximum GMSK TRX power level applied at the BTS antenna output connector in dBm.
The power takes into account the different losses (cables, internal combiners) and the internal/ external leveling
but it does not take into account the BS-TXPWR-MAX, attenuation required by the OMC_R.
If the feature unbalancing TRX output power per BTS sector" is activated (parameter En-Unbalanced-OutputPower set to 1), the counter is set by the BTS to the power required by the BSC for the corresponding TRE (i.e.
for the TRE on which is mapped that TRX).

6 C/I Statistics
1 7 49


6 C/I Statistics
6.1 C/I Generalities
Storage and Computation Methods
In order to provide an efficient storage, the "vector method" already

seen for previous RMS statistics will be used for C/I counters
C/I expressed in logarithmic scale (dB)

(C/I)dB
= CdBm - IdBm = 10 log10(CmW) - 10 log10(ImW)

= 10 log10(C/I)mW
1 7 50


6 C/I Statistics
6.2 C/I Parameters
RMS Parameters
C/I statistics:
parameters defining intervals for C/I statistics
MEAS_STAT_C_I1 to MEAS_STAT_C_I9: 9 thresholds on the
Carrier/Interference ratio defining 10 C/I bands
-63 < MEAS_STAT_C_I(i) MEAS_STAT_C_I(i+1) +63 dB
EN_BALANCED_CI: boolean indicating if the C/I value reported by the BTS is

balanced or not
NEIGB_CELL_ID: (BCCH,BSIC) of the neighboring cell for which the C/I
statistics per neighboring cell are reported
Frequency ARFCN: ARFCN of the frequency for which the C/I statistics per
MAFA frequency are reported
Annex 2
1 7 51

RMSpt1 = TAB_PAR_MEAS_STAT_C/I = Table of 9 parameters MEAS_STAT_C_Ii
RMSp80 = NEIGB_CELL_ID
RMSp90 = Frequency ARFCN
For C/I statistics per neighboring cell:
The C/I ratio is computed by the BTS from each Measurement Result message as the difference between:
the downlink signal level measured by the MS on the serving TCH channel = C (dBm)
the downlink signal level measured by the MS on the neighboring BCCH channel = I (dBm)
Two computation formulae may be used taking into account a corrective factor in case DL Power Control is
used in the serving cell:
If EN_BALANCED_CI = False
then C/I (dB) = RXLEV_DL (dBm) - RXLEV_NCELL (dBm)
else C/I (dB) = RXLEV_DL + abs(BS_TXPWR - BS_TXPWR_MAX) - RXLEV_NCELL

The expression (RXLEV_DL + abs(BS_TXPWR - BS_TXPWR_MAX)) can be seen as a kind of normalized
received power level in case the BTS would always have used the maximum allowed transmit power level
on the TCH channel.
For C/I statistics per MAFA frequency:

The C/I ratio is computed by the BTS from each Extended Measurement Report message in the same way as the
C/I ratio per neighboring cell.

6 C/I Statistics
6.3 C/I Counters
RMS Counters
C/I statistics per neighboring cell

TPR_CIN: vector of 10 elements C/In(C/I band j), each element is made up
of:
the norm of number of measurement result samples for which the computed
Carrier/Interference ratio is in C/I band j
MR_CIN:
maximum value of the 10 real numbers of samples for which the computed
Carrier/Interference ratio is in C/I band j (j=1 to 10)
TPR_CIN and MR_CIN counters are provided for up to 42 neighboring cells
1 7 52

RMS8a=TPR_CIN
RMS8b=TMR_CIN
For each reported neighboring cell (BCCH/BSIC):

the Real number of Measurement Results for which the computed Carrier/Interference ratio is in C/I band j,
is equal to:
S(C/I band j) x Max / 254
TPR_CIN(j) x TMR_CIN / 254
For each declared/reported neighboring cell, the identification of this cell shall be done as follows: BCCH_ARFCN
and BSIC.
The BCCH ARFCN is deduced in the BTS from the BCCH frequency index and the list of indexed frequencies (sent
by the BSC at the beginning of the RMS job).
The RMS results report shall include all reported neighboring cells. Some of them correspond to known cells at
the BSS level (i.e. their BSIC matches what is expected at the BSC side) but some of them are unknown (their BSIC
does not match). However, the BTS will handle the same for both cases.
The list of frequencies to be monitored by the mobile is limited to 33 but due to resurgence, the same
frequency can be reported several times (each time with a different BSIC). If the number of reported cells is
above the dimensioning limit (maximum 42 CI-vectors are reported), the extra new reported frequencies are not
taken into account anymore. In the result report, the related overflow indicator is set accordingly.
6 C/I Statistics
6.3 C/I Counters [cont.]
RMS Counters
C/I statistics per MAFA Frequency

TPR_CIF: vector of 10 elements C/If(C/I band j), each element is made up of:
the norm of number of Extended Measurement Results samples for which the
computed Carrier/Interference ratio is in C/I band j
MR_CIF:
maximum value of the 10 real numbers of samples for which the computed
Carrier/Interference ratio is in C/I band j (j=1 to 10)
TPR_CIF and MR_CIF counters are provided for up to 21 frequencies (serving cell
BCCH + 20 MAFA frequencies)
1 7 53

RMS9a=TPR_CIF
RMS9b=TMR_CIF
For each reported MAFA frequency (ARFCN):

the Real number of Extended Measurement Results for which the computed Carrier/Interference ratio is in
C/I band j, is equal to:
S(C/I band j) x Max / 254
TPR_CIF(j) x TMR_CIF / 254
For each reported MAFA frequency, the identification of this frequency shall be done as follows: Frequency
ARFCN.
In case of a frequency reported via an Extended Measurement Reporting, no BSIC is required: the frequency
ARFCN is not directly linked to a BCCH frequency. The ARFCN value of the frequency is deduced in the BTS from
the place of the measurement in the EXTENDED_ MEASUREMENT_REPORT and from the ordered frequency list in
the Extended Measurement Order. This list is built by the OMC-R and passed via BSC to BTS at the beginning of
the RMS job.
The maximum number of frequencies in the order (EMO) is the maximum defined in GSM (=21). Hence the
maximum in the report is 21 too. When in exceptional cases, more results are available (future expansion in
GSM), only the first 21 are reported.
The BCCH frequency of the serving cell shall 3JK12197AAAAWBZZA

always be part of Issue
the EMO-frequency
list.
1
1 7 54


7.1 Suspecting a Voice Quality Problem
Percentage of Noisy calls
Voice Quality indicators

are based on calls
Noisy calls are associated
with a cause of
bad coverage,
interference or with an
undefined cause
FER is more reliable than RXQUAL to assess VQ

Noisy calls indicators can also be computed from FER measurements
Noisy calls with bad or good FER
Calls not detected as noisy but with bad FER
1 7 55

The fact that FER measurements are more reliable than RXQUAL ones to assess the VQ is even more true when
using Slow Frequency Hopping. In this case, RXQUAL values are not anymore correlated to Voice Quality as
perceived by the end user.
FER measurements are available for the uplink path only.
Number of Noisy calls suffering from problem of bad coverage on the uplink path
RMVQULVN = RMS_call_noisy_UL_bad_coverage
Number of Noisy calls suffering from problem of interference on the uplink path
RMVQUIFN = RMS_call_noisy_UL_interference
Number of Noisy calls suffering from problem of interference and bad coverage considered together on the
uplink path
RMVQUUKN = RMS_call_noisy_UL_undefined
Rate of Noisy calls suffering from problems of interference or/and bad coverage on the uplink path
RMVQUNOR = RMS_call_noisy_UL_rate
Note: The 4 indicators above can be provided for Noisy calls suffering of VQ problems on the dowlink path.
Rate of Noisy calls but with good FER measurements on the uplink path
RMVQFEGR = RMS_call_noisy_good_FER_rate
Rate of Noisy calls and also with bad FER measurements on the uplink path
RMVQFEBR = RMS_call_noisy_bad_FER_rate
Rate of calls with fair quality measurements but with bad FER measurements on the uplink path
RMVQFEAR = RMS_call_abnormal_bad_FER_rate
This last indicator can be used in order to tune the RMS VQ parameters used to characterize a call as Noisy.

7.2 Suspecting a Cell Coverage Problem
Distribution of samples per RxQual value and RxLev band
Not acceptable
coverage limit:
Too low level
Too bad quality
Distribution of samples per RxLev band
1 7 56

A coverage problem is observed when a significant amount of the traffic of a cell is suffering from both low level
and bad quality (RxQual).
To confirm the distribution of samples per RXLEV band, should be also considered to know the proportion of calls
which are experiencing a low signal level.
If a lot of samples of low level and bad quality are observed for only a sub-part of the TRXs (can be one only)
then a BTS hardware problem or a problem on the aerials should be suspected.
If all the TRXs are experiencing a lot of samples of low level and bad quality then a coverage problem shall be
suspected.
Matrix of Number of Measurement Results per DL RxQual value and per DL RxLev band
RMQLDSAM = RMS_DL_RxQuality_RxLevel_sample
Vector of Percentage of Samples per DL RxLev band

RMQLDLVDV = RMS_DL_RxLevel_distrib
Vector of Percentage of Samples per DL RxQual band

RMQLDQUDV = RMS_DL_RxQuality_distrib

7.2 Suspecting a Cell Coverage Problem [cont.]
Average TA values per RxQual value and RxLev band
Not acceptable
coverage limit:
Too low level
Too bad quality
Acceptable coverage limit:

Sufficient level and good quality
% of TA value over TA
threshold has also to be
considered
1 7 57

In order to know if the coverage problem is due to a big amount of traffic at the cell border or rather to indoor
calls, the average TA value per RXQUAL value and RXLEV band as well as the Percentage of TA values over the TA
threshold should be observed.
Matrix of Average TA per UL RxQual value and per UL RxLev band
RMQLUTAM = RMS_UL_RxQuality_RxLevel_TimingAdvance
Rate of Measurements Results whose TA is greater than the TA threshold

RMTAGTR = RMS_TimingAdvance_greater_threshold_rate
Maximum TA value of all values reported in Measurement Results

RMTAMXN = RMS_TimingAdvance_max

Exercise 1
Give the list of the RMS counters and parameters used in the 3 previous
slides.
Time allowed:
10 minutes
1 7 58


Exercise 2
Interpret this
graph.
Time allowed:
10 minutes
1 7 59


Number of samples per RxQual value and RxLev band
Average DL RxQuality = 0.34
RMS results show no problem

of radio link quality in this cell
Average RxQual value per
RxLev band has also to be
considered
1 7 60

Matrix of Number of Measurement Results per DL RxQual value and per DL RxLev band
RMQLDSAM = RMS_DL_RxQuality_RxLevel_sample
Vector of Average DL RxQual per RxLev band

RMQLDQUAV = RMS_DL_RxQuality_avg_per_RxLevel
Average DL RxQuality
RMQLDQUAN = RMS_DL_RxQuality_avg

Exercise 3
Interpret this
graph.
Average DL RxQuality =
2.81
Average RxQual value per

RxLev band has also to be
considered
1 7 61


Exercise 4
Interpret this
graph.
Time allowed:
15 minutes
1 7 62


Exercise 5
Interpret
this graph.
Time allowed:
10 minutes
1 7 63

Rapport NPO :
Alc_Mono_Carrier_over_interference

1 7 64


RMS Counters
Counters used for post-processing the RMS results provided per TRX
TOT_SEIZ_TCH: number of TCH channels successfully seized by the MS
TOT_MEAS: number of Measurement Results used for RMS
TOT_MEAS_L1INFO_NOL3INFO: number of Measurement Results used for RMS
statistics for which Layer 1 info is present but Layer 3 is missing
TOT_MEAS_DTX_UL: number of Measurement Results used for RMS statistics
for which DTX UL was used in the corresponding SACCH mfr
TOT_MEAS_DTX_DL: number of Measurement Results used for RMS statistics
for which DTX DL was used in the corresponding SACCH mfr
TOT_EMR: number of Extended Measurement Results used for RMS statistics
1 7 65

RMS31 = TOT_SEIZ_TCH
RMS32 = TOT_MEAS
RMS33 = TOT_MEAS_L1INFO_NOL3INFO
RMS34 = TOT_MEAS_DTX_UL
RMS35 = TOT_MEAS_DTX_DL
RMS38 = TOT_EMR
Note:
If during an SACCH measurement, DTX is applied on the uplink path (DTX_UL =1), the counters on consecutive
BFIs (RMS5a, RMS5b) shall not be incremented and the corresponding measurement result shall not be taken into
account in these RMS counters.
If during an SACCH measurement, DTX is applied on the uplink path (DTX_UL = 1), the FER measurement does
not take place.

RMS Counters [cont.]
Counters used for interpreting the RMS results provided per TRX:
TRE_BAND: frequency band of the TRX
BS_TX_PWRMAX: effective maximum output power of the BTS on any channel
of the TRX as an offset from the maximum absolute output power (in dB)
MS_TX_PWRMAX: effective maximum output power of the MS using any
channel of the TRX (in dBm)
IND_TRE_OVERLOAD: boolean indicating if the TRE handling the TRX function
has experienced a data loss due to a processor overload during the RMS
campaign
IND_RMS_RESTARTED: boolean indicating if the RMS job has been restarted on
the concerned TRE during the RMS campaign due to a modification of the RMS
parameter values or a TRE reset
1 7 66

Corresponding RMS counter numbers: RMS20 = TRE_BAND
RMSpw1 = BS_TX_PWRMAX
RMSpw2 = MS_TX_PWRMAX
RMS21 = IND_TRE_OVERLOAD
RMS22 = IND_RMS_RESTARTED

RMS Counters [cont.]
Counters used for interpreting the C/I RMS results provided per TRX:
IND_CI_PARTIAL_OBSERVATION: made up of 2 booleans indicating that:
C/In computation has been restarted due to the modification of the list of
neighboring cells during the RMS campaign
C/If computation has been restarted due to the modification of the list of MAFA
frequencies during the RMS campaign
IND_CI_OVERFLOW: boolean indicating that the upper limit of 42 C/I sets of

counters has been exceeded (each new reported neighboring cell (BCCH,
BSIC) has not been taken into account in RMS statistics)
1 7 67

RMS23 = IND_CI_PARTIAL_OBSERVATION
RMS24 = IND_CI_OVERFLOW


for this module
1 7 68


End of Module
RMS Indicators
1 7 69


Section 1
Module 8
Traffic Indicators
GSM B11

Blank Page
182
B11 GSM QoS Monitoring Traffic Indicators

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module Objectives
Describe BSS traffic indicators used for radio resource dimensioning
183


184


Table of Contents
Page

1 Call Mix Definition
GSM Transactions
Example
Variation
Usage
Advises
Exercise
2 Basis of Traffic Theory
Erlang Definition
Erlang from Call Mix
Erlang B Law
Erlang B Formulae
Erlang B Abacus
Erlang B Example
Non Linearity of Erlang B
Cell Dimensioning
Dimensioning "a Priori"
Dimensioning "a Posteriori"
Forecast / Critical Traffic
Exercise
3 TCH Resource Allocation Indicators
Radio Allocation and Management
MS Access
185
Speech
Coding
TrafficVersion
Indicators
Distributions
4 Resource Occupancy Indicators
TCH Resource
TCH Resource
SDCCH / ACH Resource
5 Traffic Model Indicators
SDCCH Establishment Cause
Mobiles Penetration
SDCCH traffic indicators
TCH traffic indicators
6 Preemption Indicators
Preemption Principle
Preemption Counters
Preemption Feature
End of Module

7
8
10
11
12
13
14
15
16
17
18
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
41
43
44
45
46
47
48
49
50

186


187


GSM Transactions
In a GSM Network, there are a lot of different transactions:
location update: periodic, new updating, ~imsi_attach, ~imsi_detach

Hand Over (intra-cell, internal, external, etc.)
SMS (Short Message Service, originating or terminating)
SS (Supplementary Service) (i.e: number presentation)
Paging
and also Originating and Terminating calls, etc.
and so on (data, SMS-CB, etc.)
188

In a GSM network, telecom procedures involve different kind of resources in the BSS:
Location Update: RACH, AGCH, SDCCH and SCCP
Originated Call: RACH, AGCH, SDCCH, TCH and SCCP
Terminated Call: PCH, RACH, AGCH, SDCCH, TCH and SCCP
Handover: TCH, SCCP
etc.

GSM Transactions [cont.]
One can quantify the number of each transaction per hour
For example, for one cell, one can measure:
900 calls (600 TCs, 300 OCs)

3600 LUs (any type)
1350 HOs (900 internal, 450 external)
100 SMSs
5 SSs
6000 pagings
With the following characteristics
mean call duration on TCH: 50 seconds
mean SDCCH duration: 3.2 seconds
189

A Call mix can be defined through:
data given by the Marketing team.
data measured from the living network.
Before network design, a Call Mix is assessed from Marketing Studies or observations from other networks.
After commercial opening, a Call Mix is measured from the real traffic.
Caution: Call duration means here TCH duration. The duration of a call from call setup to call release is an NSS
notion.

Example
Set of such measurements is called "call mix"

sometimes improperly called "traffic model"
Usually presented in the following way:
Calls /hour
:
LU/call
:
HO/Call
:
SMS/Call
:
SS/call
:
Paging/hour
:
mean call duration on TCH :
mean SDCCH duration
:
1 8 10
900 (2/3 TC)

4
1.5 (2/3 internal, 1/3 external)
11 %
5%
6000
90 seconds
4.2 seconds

After commercial opening, the number of calls per hour will be measured from traffic counters.
Usually the Marketing team will provide:
on a per geographical area or morphostructure basis:
the traffic per km2 (in Erlang),
the traffic per subscriber (in mErl).
the number of calls per hour.

Variation
A call mix is varying a lot:

from a cell to another
TCH traffic (induced by subscribers)
number of LU/call and HO/call (induced by network design)
from one hour to another

by default: busy hour
from one year to another

modification of traffic intensity and distribution
1 8 11

On some university campus, an SMS/call is often higher than the average.

Usage
Interests of call mix: Input data for dimensioning

Cell and BSC resources dimensioning
RTCH, SDCCH, TTCH, BTS, BSC and MSC CPU processor
Some examples of "risky" call mix
too many LU/Calls: SDCCH congestion, TCU load, MSC overload

too many HO/calls: speech quality, call drop, DTC load
too many calls: TCH congestion
too many paging: DTC processor load, PCH congestion
1 8 12

A Call Mix will be used at Radio Network Design and Radio Network Planning stages in order to define the capacity of
the network (number of sites, TRXs per site, radio configuration, number of Abis-PCM, A-PCM).
When the network is in operation, a Call Mix is used in order to anticipate network extension or re-dimensioning.

Advises
Some advises
LU/CALL: 1 is "good", 2 is "bad", 4 and more can be dangerous
beware of the Network or BSC averages which can hide critical cells
HO/Call: less critical (1 is good)

2 or 3 is not a direct problem, but the trend has to be monitored
Call: to be checked with an Erlang table (seen in next session)
1 8 13


Exercise
Compute the call mix of a cell according the following information:

256 calls/hour
1300 LUs/hour
450 HOs/hour
Is it complete?
What are the risks of such a call mix?
Time allowed:
15 minutes
1 8 14


1 8 15


Erlang Definition
ERLANG: unit used to quantify traffic (intensity)

T = (resource usage duration) / (total observation duration) [ERLANG]
Example:
For 1 TCH, observed during 1 hour
one can observe 2 calls: 1 of 80 seconds and 1 of 100 seconds
T = (80+100)/3600 = 0.05 ERLANG
1 8 16


Erlang from Call Mix
Call mix example:
350 calls/hour
3 LUs/call
TCH mean call duration: 85 seconds
SDCCH mean duration: 4.5 seconds
Computation of Carried Erlang

TCH = (350*85)/3600: 8.26 ERLANGS
SDCCH = [ (350+350*3) * 4.5 ] / 3600 = 1.75 Erlang
1 8 17


Erlang B Law
In a Telecom system, the call arrival frequency is ruled by the POISSON

law
Erlang B law: relationship between:
offered traffic
number of resources
blocking rate
1 8 18


Erlang B Law [cont.]
The call request arrival rate (and leaving) is not stable

number of resources = average number of requests * mean duration
is sometimes not sufficient => probability of blocking
=> Erlang B law

Pblock: blocking probability
N: number of resources
E: offered traffic [Erlang]
Offered
Rejected
Carried
Telecom system
Good approximation when the blocking rate

is low (< 5 %)
P block
1 8 19
N
k 0
N!
k!

The Erlang B law is not fully accurate since it assumes that:
the subscriber requests are not queued which is not always the case (TCH queued in the BSC),
the subscriber does not repeat his call request if rejected, which is almost never the case.
Therefore the higher the blocking rate the worse is the approximation of the Erlang B law.
The Erlang C law modelizes better the TCH resource usage of the BSS since it takes into account the queuing.
However the Erlang C law is never used since parameters like size of the queue and time spent into the queue have
to be tuned.

Erlang B Formulae
There are two different ways to use this law

Using Abacus
Using SW (here Excel)
Pblock = f (T, Nc)
Offered = f (Nc, Pblock)
Channels = f (T, Pblock)
1 8 20


Erlang B Abacus
1 8 21


Erlang B Example
Example:
1 cell with 8 TRXs, with 60 TCH channels
Maximum blocking rate: 2 %
Erlang law: 50 Offered Erlang
83 % of TCH resources used to reach 2% of blocking
1 8 22


Non Linearity of Erlang B
But be careful, the Erlang B law is not linear:

If we use for example a combined BCCH with a micro BTS.
4 SDCCHs, Pblock = 2% =>
T = 1.1 E
25% resources used to reach 2% blocking
if we decide to provide SMSCB (Cell Broadcast information),

1 SDCCH stolen for CBCH
3 SDCCHs, Pblock = 2%
25% resources less
1 8 23
=>
=>
T = 0.6 E
50% Traffic less!!


Cell Dimensioning
Given an Offered traffic, compute the number of TRXs (and SDCCH)

needed to carry it => What is the accepted blocking rate?
Default blocking rate

RTCH: 2 %
SDCCH: 0.5 %
(for BSC TTCH: 0.1%)
1 8 24

The Erlang B law is less relevant for SDCCH dimensioning since SDCCH traffic cannot be modelized like TCH traffic.
Indeed SDCCH is not only due to subscriber traffic but also to Location Update, SMS, IMSI Detach, etc.
For SDCCH dimensioning, some typical configurations are used according to the number of TRXs in the cell, the LA
plan.

Dimensioning "a Priori"
Cell dimensioning from call mix (bid, architecture)

to handle an offered traffic of 12 Erlangs (RTCH), compute the number of
channels, then the number of TRXs
Channels (12;2%) = 19
example: 3 TRXs, 21 TCHs, 1 BCCH, 2 SDCCHs/8
1 8 25


Dimensioning "a Posteriori"
Cell dimensioning from measurement (re-planning)

one is measuring a traffic of 15 Erlangs, with a blocking rate of 10%
how to dimension the cell?
Offered traffic = 15 / (1-10%) = 16.7 Erlangs!!!!
Channels (16.7;2%) -> 25 TCHs -> 4 TRXs needed
1 8 26


Forecast / Critical Traffic
Forecast traffic
traffic forecasting must be computed according to the offered traffic
not directly on the measured traffic
In order to plan the necessary actions soon enough, one must compute
regularly the date when the traffic of a cell will become critical
Critical traffic
critical traffic: when the offered traffic will induce 2% of blocking
traffic capacity of a cell = critical traffic of this cell
1 8 27


Exercise
Complete the form to get less than 2% of blocking.
cell
call mix info
12, 743
450 call/ hour

10,08 Erlang TCH 30 % offered traffic 13,1 Erlang TCH - > 20 TCH
mean TCH call duration : 80
increase
3 TRX
sec
blocking rate TCH : 0.8%
12,675
330 call/ hour

mean TCH call duration 129
sec
blocking rate 4%
600 call/ hour
mean TCH call duration 96
sec
blocking rate 8 %
12,865
1 8 28
Erlang TCH
Offered traffic
traffic forecast
30 % offered traffic
increase
30 % offered traffic
increase


proposed config
1 8 29


Radio Allocation and Management
Radio resource allocation and management (RAM) aims at:

Managing pools of TCH radio resources by:
defining TCH radio timeslots as a function of the cell radio configuration from the
operator
sorting these TCH TSs according to their radio capabilities (FR or DR, frequency band
(G1 or GSM/DCS))
Allocating dedicated TCH radio resources by:

selecting the TCH pool in which the TCH should be chosen according to:
the requested channel rate (FR or HR)

the radio capability of the mobile
the TRE DR capability and the TRE band
selecting the best TCH resource among the available TCH channels of this pool
according to several criteria
1 8 30


MS Access
MS access types distribution (NA only)

Accessibility in type 110 since B8
TCH requests from FR only MS
TCNARQMN= MC701A
TCH requests from DR MS
TCNARQBN= MC701B
TCH requests from DR+EFR MS
TCNARQTN= MC701C
TCH requests from AMR MS
TCNA3RQTN= MC701D
TCH requests from Data calls
TCNARQDN= MC701E
1 8 31


Traffic Load and Traffic Model > TCH traffic > Speech version and Channel type
These indicators can only be computed if PM Type 1 is activated in B7. From B8, the counters needed for these indicators are
added to type 110.
The following indicators are also computed:
Ratio of TCH normal assignment requests from FR mobiles over all TCH normal assignment requests from all mobile types
= TCNARQMTO = MC701A / (MC701A+MC701B+MC701C+MC701D+MC701E)
Ratio of TCH normal assignment requests from DR mobiles over all TCH normal assignment requests from all mobile types
= TCNARQBTO = MC701B / (MC701A+MC701B+MC701C+MC701D+MC701E)
Ratio of TCH normal assignment requests from DR+EFR mobiles over all TCH normal assignment requests from all mobile types
= TCNARQTTO = MC701C / (MC701A+MC701B+MC701C+MC701D+MC701E)
Ratio of TCH normal assignment requests from AMR mobiles over all TCH normal assignment requests from all mobile types
= TCNA3RQTTO = MC701D / (MC701A+MC701B+MC701C+MC701D+MC701E)
Ratio of TCH normal assignment requests for Data calls over all TCH normal assignment requests from all mobile types
= TCNARQDTO = MC701E / (MC701A+MC701B+MC701C+MC701D+MC701E)
Number of handover intracell attempts with cause 27: "FR to HR channel adaptation due to a good radio quality" on a TCH
channel
= HCSTAMFN = MC448B
Number of handover intracell attempts with cause 26: "HR to FR channel adaptation due to a bad radio quality" on a TCH channel
= HCSTAMHN = MC448A

Speech Coding Version
Speech coding Version capabilities distribution (NA only)

Accessibility in type 110 since B8
TCH allocations with FR SV1
TCNACAFN= MC702A
TCH allocations with HR SV1
TCNACAHN= MC702B
TCH allocations with FR SV2 (EFR)
TCNACAEN= MC702C
TCH allocations with FR SV3 (AMR FR)
TCNA3CAFN= MC704A
TCH allocations with HR SV3 (AMR HR)
TCNA3CAHN= MC704B
TCH allocations for data call
TCNACADN= MC705
1 8 32


These indicators can only be computed if PM Type 1 is activated in B7. From B8, the counters needed for these
Indicators are added to type 110.
The following indicators are also computed:
Ratio of TCH allocations with FR SV1 over all TCH allocations during normal assignment
= TCNACAFTO = MC702A / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
Ratio of TCH allocations with HR SV1 over all TCH allocations during normal assignment
= TCNACAHTO = MC702B / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
Ratio of TCH allocations with EFR over all TCH allocations during normal assignment
= TCNACAETO = MC702C / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
Ratio of TCH allocations with AMR FR over all TCH allocations during normal assignment
= TCNA3CAFTO = MC704A / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
Ratio of TCH allocations with AMR HR over all TCH allocations during normal assignment
= TCNA3CAHTO = MC704A / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
Ratio of TCH allocations for Data calls over all TCH allocations during normal assignment
= TCNACADTO = MC705 / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
Rate of successful TCH allocations with AMR SV over all AMR MS requests
= TCNA3SUR = (MC704A+MC704B) / MC701D

Distributions
FR/HR calls distribution (NA+HO)

FR TCH allocation ratio
TCAHCAFO = MC370A / (MC370A+MC370B)
HR TCH allocation ratio
TCAHCAHO = MC370B / (MC370A+MC370B)
NA/HO distribution
Normal Assignment TCH allocation ratio
TCNACAO = MC703 / (MC703 + [MC15A+MC15B])
Handover TCH allocation ratio
TCHOCAO = [MC15A+MC15B] / (MC703 + [MC15A+MC15B])
TCH allocation distribution per TRX

Number of TCH allocations for Normal Assignment
TCNACAN = MC703
1 8 33


Traffic Load and Traffic Model > TCH traffic > Resource occupancy
MC370A = Number of FR TCH allocations (FR+EFR+AMR FR)

MC370B = Number of HR TCH allocations (HR+AMR HR)
MC703 = Number of TCH allocations for Normal Assignment
MC15A = Number of TCH allocations for Internal Directed Retry
MC15B = Number of TCH allocations for Handover (intra cell, internal, external)
TCNACAN indicator is also available as the MAX value of the day on the NPO tool.
Some of these indicators are also available for SDCCH:
SDCCH allocation distribution per TRX through the number of SDCCH allocations
SDAHCAN = MC390
SDCCH Assignment/HO distribution through the ratio of SDCCH allocations for Assignment
SDNACAO = MC148 / MC390

1 8 34


TCH Resource
TCH resource occupancy

TCH traffic in Erlang
TCTRE= (MC380A+MC380B) / 3600
TCH mean holding time (TCH average duration)
TCTRMHT= (MC380A+MC380B) / (MC370A+MC370B)
FR TCH traffic in Erlang
TCTRE= MC380A / 3600
FR TCH mean holding time
TCTRFMHT= MC380A/ MC370A
HR TCH traffic in Erlang
TCTRE= MC380B / 3600
HR TCH mean holding time
TCTRHMHT= MC380B/ MC370B
1 8 35


Traffic Load and Traffic Model > TCH traffic > Resource occupancy
MC380A = Cumulated FR TCH duration per TRX
MC380B = Cumulated HR TCH duration per TRX
The following indicators can also be computed:
TCTRME = Multiband MS TCH traffic in Erlang = MC381 / 3600
TCTRSE = Single band MS TCH traffic in Erlang = ([MC380A+MC380B] - MC381) / 3600
MC381 = Cumulated (FR+HR) TCH duration of Multiband mobiles per TRX

A split of counters (MC380a and MC380b) is added, in B8, to make the distinction between traffic in different
frequency bands: here after the corresponding stored indicators (type 110):
TCTRFTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the GSM
frequency band is busy in FR usage = MC380C
TCTRHTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the GSM
frequency band is busy in HR usage = MC380D
TCTRFTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the DCS/PCS
frequency band is busy in FR usage = MC380E
TCTRHTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the DCS/PCS
frequency band is busy in HR usage = MC380F

TCH Resource
Alc_Mono_RTCH_Traffic_Model
Alc_Half_rate_erlang - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) - 17/05/2009 00 00:00 To
17/05/2009 23 23:00 (Working Zone: Global - Medium)
30
30
25
25
20
20
15
15
10
10
half Erl total

full Erl total
RTCH Erl total
09
2
09 2 2
2 2:
09 3 2 00
0 3:
09 0 0 00
0 0:
09 1 0 00
0 1:
09 2 0 00
0 2:0
09 3 0 0
0 3:
09 4 0 00
0 4:
09 5 0 00
0 5:
09 6 0 00
0 6:
09 7 0 00
0 7:
09 8 0 00
0 8:
09 9 0 00
1 9:
09 0 1 00
1 0:
09 1 1 00
1 1:
09 2 1 00
1 2:
09 3 1 00
1 3:
09 4 1 00
1 4:
09 5 1 00
1 5:0
09 6 1 0
1 6:
09 7 1 00
1 7:
09 8 1 00
1 8:
09 9 1 00
2 9:
09 0 2 00
21 0:0
21 0
:0
0
Er
35
Er
35
1 8 36

TCH resource occupancy
TCH traffic in Erlang

TCTRE= (MC380A+MC380B) / 3600
TCH mean holding time (TCH average duration)

TCTRMHT= (MC380A+MC380B) / (MC370A+MC370B)
FR TCH traffic in Erlang

TCTRE= MC380A / 3600
FR TCH mean holding time

TCTRFMHT= MC380A/ MC370A
HR TCH traffic in Erlang

TCTRE= MC380B / 3600
HR TCH mean holding time

TCTRHMHT= MC380B/ MC370B
TCTRFTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the GSM
frequency band is busy in FR usage = MC380C
TCTRHTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the GSM
frequency band is busy in HR usage = MC380D
TCTRFTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the DCS/PCS
frequency band is busy in FR usage = MC380E
TCTRHTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the DCS/PCS
frequency band is busy in HR usage = MC380F

SDCCH / ACH Resource
SDCCH resource occupancy

SDCCH traffic in Erlang
SDTRE= MC400 / 3600
SDCCH mean holding time (SDCCH average duration)
SDTRMHT= MC400 / MC390
ACH resource occupancy

ACH traffic in Erlang
C750 / 3600
ACH mean holding time (ACH average duration)
QSTRN =C750 / C751
1 8 37


Traffic Load and Traffic Model > SDCCH traffic > Resource occupancy
MC400 = Cumulated SDCCH duration per TRX
MC380 = Number of SDCCH allocations per TRX
C750 and C751 are 2 counters introduced from B7 in type 18. Both are provided per TTCH (A channel):
C750 = TIME_A_CHANNEL_BUSY: Time (in seconds) during which the A channel is busy (allocated)
C751 = NB_A_CHANNEL_ALLOC: Number of allocations of the A channel

1 8 38


SDCCH Establishment Cause
Alc_Mono_SDCCH_Traffic_Model
MS originated traffic split - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017
) - 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone: Global - Medium)
100%
90%
LCS
80%
Other
70%
IMSI detach
nb
60%
Suppl Service
50%
SMS
40%
LU FOR
30%
Location Update
20%
MOC
10%
16
/0
5/
20
09
22
17
/0
22
5/
:0
20
0
09
00
17
/0
00
5/
:0
20
0
09
02
17
/0
02
5/
:0
20
0
09
04
17
/0
04
5/
:0
20
0
09
06
17
/0
06
5/
:0
20
0
09
0
17
8
/0
08
5/
:0
20
0
09
1
17
0
/0
10
5/
:0
20
0
09
12
17
/0
12
5/
:0
20
0
09
14
17
/0
14
5/
:0
20
0
09
16
17
/0
16
5/
:0
20
0
09
18
17
/0
18
5/
:0
20
0
09
20
20
:0
0
0%
1 8 39


SDCCH Establishment Cause [cont.]
SDCCH establishment cause distribution

Ratio of MT calls
TMMTO= MC01 / SDCCH ASSIGN SUCCESS
Ratio of MO normal and emergency calls
TMMTO= MC02H / SDCCH ASSIGN SUCCESS
Ratio of LU normal (resp. follow-on)
TMMOLUR = MC02A (resp. MC02D) / SDCCH ASSIGN SUCCESS
Ratio of IMSI detach
TMMOLUDR= MC02G / SDCCH ASSIGN SUCCESS
Ratio of Short Message Service
TMMOSMSR= MC02B / SDCCH ASSIGN SUCCESS
Ratio of Supplementary Service
TMMOSSR= MC02C / SDCCH ASSIGN SUCCESS
Ratio of Call re-establishment
TMMOCRR= MC02E / SDCCH ASSIGN SUCCESS
1 8 40


Traffic Load and Traffic Model > SDCCH traffic > Traffic model
SDCCH ASSIGN SUCCESS = Total number of SDCCH establishments for network access = MC01 + MC02
These indicators allow to get call mix data from the network.

Mobiles Penetration
Alc_Mono_SpeechVersion_and_ChannelType_detailed
Split of requests - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone: Global - Medium)
100%
80%
Data
AMR
nb
60%
DR_EFR
40%
DR
FR
20%
16
/0
5/
20
09
22
17
/0
22
5/
:0
20
0
09
00
17
/0
00
5/
:0
20
0
09
17
02
/0
02
5/
:0
20
0
09
04
17
/0
04
5/
:0
20
0
09
06
17
/0
06
5/
:0
20
0
09
17
08
/0
08
5/
:0
20
0
09
10
17
/0
10
5/
:0
20
0
09
1
17
2
/0
12
5/
:0
20
0
09
17
14
/0
14
5/
:0
20
0
09
16
17
/0
16
5/
:0
20
0
09
18
17
/0
18
5/
:0
20
0
09
20
20
:0
0
0%
1 8 41


Mobiles Penetration [cont.]
E-GSM mobiles penetration

Ratio of E-GSM MS access over all MS accesses (except LU)
TMMSEGR = MC706 / ([MC01+MC02]-[MC02A+MC02D+MC02G])
Multiband mobiles penetration

Ratio of Multiband MS access over all MS accesses (except LU)
TMMSMBR = MC850 / ([MC01+MC02]-[MC02A+MC02D+MC02G])
AMR mobiles penetration

Ratio of TCH allocation for AMR MS over all TCH allocations
TCTR3CATTO = MC704A+ MC704B / MC703
TFO calls ratio

Ratio of successful TFO establishment over all TCH allocations
QSTRCCTR = MC170 / MC703
Handover per Call

Number of Handovers (intra cell, internal, external) per Normal Assignment
TMHOCO = (MC717A+MC717B) / MC718
1 8 42

Traffic Load and Traffic Model > SDCCH traffic > MS penetration rate
[MC01+MC02]-[MC02A+MC02D+MC02G] = Total number of initial accesses for call establishment (except location
update)
MC706 = Number of initial accesses for call establishment (except location update) of MS supporting the E-GSM
band
MC850 = Number of initial accesses for call establishment (except location update) of MS supporting two frequency
bands (ex: GSM900 and DCS1800)
MC703 = Total number of TCH allocations (FR+HR) for Normal Assignment
MC704A = Number of TCH allocations (FR) for Normal Assignment of AMR mobiles only
MC704B = Number of TCH allocations (HR) for Normal Assignment of AMR mobiles only
MC704 (Allocation AMR FR+HR) is removed in B8
MC170 = Number of TCH calls for which a TFO has been successfully established

SDCCH traffic indicators
1 8 43

Report :
Alc_Mono_SDCCH_traffic

TCH traffic indicators
1 8 44

Report :
Alc_Mono_RTCH_traffic

1 8 45


Preemption Principle
Preemption attributes (in Assignment or HO Request):
pci: preemption capability indication

indicates if the call can preempt another call (pci=1) or not
pvi: preemption vulnerability indication
indicates if the call is preemptable (pvi=1) or not
priority level: 1=highest priority / 14=lowest priority
Preemption rules:
A TCH request with pci=1 and priority level=p1 will preempt an on-going
call with pvi=1 and priority level=p2, p2 lower than p1 (whatever pci
value)
the on-going call with the lowest priority level value shall be elected
first and if several calls have the same lowest p2 value, one of them
with pci bit set to 0 is preferred
1 8 46

On Preemption capable TCH Request occurrence:

1. The TCH is established through Preemption if a lower priority level on-going call is preemptable. In this case, the
on-going call is released and the freed TCH is served to the new request.
2. If no preemption is possible:
If queuing is possible: the TCH request is queued and either a Directed Retry or a Fast Traffic HO can be
performed.
If queuing is not possible: the TCH request is rejected and an ASSIGNMENT or HANDOVER FAILURE "no radio
resource available" message is sent to the MSC.

Preemption Counters
MC921A = Number of TCH Requests with the capability to preempt

another call with lower priority (pci=1)
MC921B = Number of preemption capable TCH Requests (pci=1) served
with TCH resource (with or without using the preemption feature).
MC921C = Number of preempted calls
MC921D = Number of preemption capable TCH Request (pci=1)
successfully served in a neighboring cell with the help of the directed
retry procedure
MC921E = Number of preemptable calls successfully established (pvi=1)
1 8 47


GLOBAL Quality of service INDICATORS> RTCH > Preemption feature

Preemption Feature
Preemption capable TCH Request rejection rate

TCPPFLCR = (MC921A-MC921B-MC921D) / MC921A
Ratio of preemption capable TCH Request which led to a successful

Directed Retry
TCPPDSUCR = MC921D / MC921A
Ratio of preemptable calls established over all calls

TCPPSUVO = MC921E / (MC718+MC717A+MC717B)
1 8 48


GLOBAL Quality of service INDICATORS> RTCH > Preemption feature


for this module
1 8 49


End of Module
Traffic Indicators
1 8 50


Section 1
Module 9
Case Studies
GSM B11

Blank Page
192
B11 GSM QoS Monitoring Case Studies

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module Objectives
Analyze with the KPI QoS some typical problems
193


194


Table of Contents
Page

1 Congestion
Congestion Analysis
2 Sector Problem
Scetor Problem Analysis
3 QSCSSR
QSCSSR Analysis
4 Quality
Quality Analysis
5 RMS Level
RMS Level Analysis
6 Interference
Interference Analysis
7 BSS Problem
BSS Problem Analysis
End of Module
195
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22



196


1 Congestion
197


1 Congestion
Congestion Analysis
From this NPO table: What is the worst SDCCH congested cell?
Choose 2 other interesting indicators to continue your analysis:
Call Drop %
SDCCH Assignment Failure %
Outgoing Handover Success %
SDCCH Drop %
Downlink TBF drop %
RTCH assign fail %
198


2 Sector Problem
199


2 Sector Problem
Scetor Problem Analysis
In this trisectorised site,

give the worst sector.
What can you propose to

do?
1 9 10


3 QSCSSR
1 9 11


3 QSCSSR
QSCSSR Analysis
Write the formula using the reference name (MCx) and compute the
CSSR for these 2 cells:
(1 - SDCCH_drop_%) * ( 1 - RTCH_assign_unsuccess_%)
With:
SDCCH_drop_% = SDCCH_drop / SDCCH_assign_success
RTCH_ass_Un_%= RTCH_assign_unsuccess / RTCH_assign_request
Paris_Tower_S1
Paris_City_S3
MC138
Counter
SDCCH drops on SDCCH established phase due to Radio Link Fail.
Definition
MC07
SDCCH drops during any outgoing SDCCH handover
MC137
SDCCH drops in SDCCH established phase due to BSS problem
MC01
SDCCH assign success for Mobile Terminating procedure
43
924
MC02
SDCCH assign success for Mobile Originating procedure
663
1352
MC140a
normal assignment requests for TCH establishment (HR or FR)
88
1455
MC718
TCH normal assignment successes (HR or FR)
84
1430
QSCSSR=?
1 9 12


4 Quality
1 9 13


4 Quality
Quality Analysis
Analyze the table below.

Repartition HO Quality
DL_QUAL
% DL_QUAL
UL_QUAL
% UL_QUAL
Nber of HO
22/01/2003 23/01/2003 24/01/2003 25/01/2003 27/01/2003 28/01/2003 29/01/2003 30/01/2003

64
63
69
58
26
36
32
34
3.12%
2.76%
3.27%
3.22%
1.30%
1.94%
1.69%
2.64%
55
51
433
263
338
466
1053
348
2.68%
2.23%
20.54%
14.59%
16.93%
25.09%
55.68%
27.00%
2054
2286
2108
1802
1996
1857
1891
1289
Does it seem to be a good HO causes repartition?

What can we check to analyze the problem?
1 9 14


5 RMS Level
1 9 15


5 RMS Level
RMS Level Analysis
Find the 2 worst cells in the table. Try to propose a solution!
1 9 16


6 Interference
1 9 17


6 Interference
Interference Analysis
Find 1 bad cell with some HO problem.

What can you propose to do?
1 9 18


7 BSS Problem
1 9 19


7 BSS Problem
BSS Problem Analysis
What is the worst cell?

Propose some probable solutions.
1 9 20



for this module
1 9 21


End of Module
Case Studies
1 9 22


Section 1
Module 10
Annexes
GSM B11

Blank Page
1 10 2
B11 GSM QoS Monitoring Annexes

Document History
Edition
Date
Author
Remarks
01
YYYY-MM-DD
First edition

Module Objectives
Describe
List
Explain
Identify ...
1 10 3


1 10 4


Table of Contents
1 Radio Measurement Reporting
Radio Measurement Mechanisms
Measurement Result Message
2 Extended Measurement Reporting (MAFA)
Definition
Extended Measurement Reporting Mechanisms
3 Directed Retry Indicators
Internal DR - Success Case
Incoming Internal DR - Failures
Incoming Internal DR - Congestion
Incoming Internal DR - Radio Failure
Incoming Internal DR - Counters
Incoming Internal DR - Indicators
Outgoing Internal DR - Failures
Outgoing Internal DR - Radio Failure ROC
Outgoing Internal DR - Radio Failure Drop
Outgoing Internal DR - Counters
Outgoing Internal DR - Indicators
External DR - Success
Outgoing External DR - Failures
Outgoing External DR - Radio Failure ROC
Outgoing External DR - Radio Failure Drop
Outgoing
External DR - Counters
1 10 5
Outgoing
External
DR - Indicators
Annexes
4 GSM BSS Protocol Stacks
Signaling Links
The Reference Model
BSS Protocol Stacks
Signaling on the A Interface
GSM BSS Protocols
5 LCS
LCS Function
LCS Function: Architecture
Example
LCS Counters
LCS Counters
Definitions
LCS Architecture
LCS Positioning Procedure
LCS Protocol
Positioning Methods: CI+TA Positioning
Positioning Methods: Conventional GPS
Positioning Method: Assisted GPS Positioning
LCS Impact on HO
BSS Parameters
Cell Parameters
Exercise
6 Counters on Electromagnetic Emission (EME)
Characteristics of the Feature
7 B8 Improvements
Summary
8 B9 Improvements
Summary
9 Dynamic SDCCH Allocation

Page
7
8
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
37
39
40
42
43
44
45
46
47
48
49
50
51
53
54
55
58
61
62
63
64
65
66
69
70
71
72
73

Page

Purpose
Principle
TIMESLOT Types
Allocation Algorithm
SDCCH Sub-Channel Selection
Deallocation Algorithm
O&M Configuration
10 Handover Detection for Concentric Cells
Algorithms
Handover Algorithm Cause 10
Handover Algorithms Cause 13
Outgoing Intercell Handovers from Concentric Cell
Incoming Intercell Handovers towards Concentric Cell
End of Module
1 10 6


74
75
77
78
79
80
81
83
84
85
86
87
93
94
96
97
1 10 7


Radio Measurement Mechanisms
MS connected (TCH or SDCCH)

The serving cell gives to the MS the list of the neighboring cells to listen
Every SACCH, the MS reports to the serving cell: measurement report
message
Received level of 6 best cells (which can change)
DL level and quality of serving cell
Meast
Report
1 10 8


Radio Measurement Mechanisms [cont.]
For each MS connected to the BTS (TCH or SDCCH)
Meast
Result
Meast
Report
BSC
DL measurements
UL+DL measurements
The UL received level and quality are measured every SACCH

The Timing advance (TA) is computed
The UL information is gathered into a measurement report
This is the message result sent by the BTS to the BSC
1 10 9


Measurement Result Message
L1 Info
L3 Info
Measurement
Report
From the MS
Back
1 10 10

Basically, the MEASUREMENT RESULT message is composed of:
L1 info: SACCH Layer 1 header containing MS_TXPWR_CONF and TOA.
L3 info: MEASUREMENT REPORT from the MS. This message contains the downlink measurements and neighboring
cell measurements.
Uplink measurements performed by the BTS.
BTS power level used.
SUB frames correspond to the use of DTX:

if the mobile is in DTX, the rxlevsub or rxqualsub is used to avoid measuring the TS where there is nothing to
transmit in order not to false measurements.
else rxlevfull is used that is to say all TSs are measured.
MS TXPOWER CONF: what is the actual power emitted by the MS.

TOA is the timing advance.
SACCH BFI: bad frame indicator; 2 values 0 or 1; 0 means that the BTS succeeded in decoding the measurement
report from the MS.
How are the neighboring cells coded?
BCCH1 index in BA list /BSIC1; BCCH2 index in BA list/BSIC2. Why? Because when the mobile is connecting to a new
cell, it does not receive LAC/CI (too long) but the list of BCCH frequencies of the neighboring cells (in Band
Allocation: BA list). When it reports the radio measurements, it gives the index of the BCCH frequency in the BA list
instead of BCCH ARFCN due to the length in case of 1800 frequency coding. Besides the mobile may report a BCCH
index / BSIC which does not correspond to a neighboring cell. Of course the BSC will not trigger any handover except
if this BCCH index / BSIC couple corresponds
to Reserved
a neighboring
cell. 2010
All Rights
Alcatel-Lucent
2 Extended Measurement Reporting

(MAFA)
1 10 11


Definition
The Extended Measurement Reporting is a feature allowing the BSS to

request an MS to measure and report up to 21 frequencies of the band
that are not included in its BA list
Such phase 2+ mobiles must support the optional Mobile Assisted
Frequency Allocation (MAFA) feature
1 10 12


Extended Measurement Reporting Mechanisms

MS
BTS
BSC
TCH ASSIGNMENT PHASE (OC or TC)
MSC
< ----------------------------------ASSIGNMENT REQUEST
< -------------------------------------------------------PHYSICAL CONTEXT REQUEST

-------------------------------------------------------- >
PHYSICAL CONTEXT CONFIRM
--------TCH--------->
ASSIGNT COMPLETE
< -------------------------------------------------------CHANNEL ACTIVATION (TCH)

(EMO included)
-------------------------------------------------------- >
CHANNEL ACTIVATION ACKNOWLEDGE
.
.
TCH establishment.
.
------------------------------------------------------- >
ASSIGNMENT COMPLETE
<------SACCH---------------SACCH------>
<------SACCH---------------SACCH------>
<-------SACCH-------EMO
(MAFA freq. List)
--------SACCH------>
EMR
(MAFA freq. RxLev)
<------SACCH---------------SACCH------>
----------------------------------- >
ASSIGNMENT COMPLETE
The Extended
Measurement Order
includes the MAFA
frequencies the MS is
asked to measure
EMO sent once to the MS
on SACCH after TCH
seizure
Extended Measurement
Results include the
average signal level
measured on each MAFA
frequency over one SACCH
mf duration
EMR received once per call
on SACCH
Back
1 10 13

When the BTS receives a CHANNEL ACTIVATION with the Extended Measurement Order (EMO) included, it shall
send this information on the SACCH to the corresponding mobile only once.
When the BTS has to send this information, it shall replace the sending of system information 5, 5bis, 5ter or 6 by
this information. At the next SACCH multi-frame, the BTS shall resume the sending of this system information by
the replaced one.
The EMO shall be sent after 2 complete sets of SYS_INFO5 and 6, i.e. after the 2nd SYSINFO 6 after the reception of
SABM. This guarantees the MS has received a complete set.
Then, the BTS normally receives from the MS an EXTENDED MEASUREMENT RESULT with the level of the
frequencies to monitor. The BTS shall make the correlation between these levels and the frequencies contained in
the latest EMO information, after having decoded them, according to the order of the ARFCN. The
EXTENDED_MEASUREMENT_RESULT is NOT forwarded to the BSC, instead a MEASUREMENT_RESULT with
indication no_MS_results is sent to the BSC.
In particular, the BTS shall identify the level of the BCCH frequency of the serving cell (which shall always be part
of the frequencies to monitor) and apply it as the RXLEV_DL in the Radio Measurement Statistics. The other
frequencies will be considered in the same way as BCCH frequency of neighboring cells: they will be linked to the
neighboring level and C/I statistics.

1 10 14


Internal DR - Success Case

MS
serving cell
target cell
BSC
MSC
< ----------------------ASSIGNMENT
REQUEST
Queuing allowed
No free TCH
TCH request queued
Start T11 ----------------------- >
QUEUING_INDIC.
MC13A
IDR condition met
MC153, MC144e,
CHANNEL ACTIV. (TCH)

<---------------------------------- MC15A
CHAN ACTIV ACK
---------------------------------->
HO CMD
HANDOVER COMMAND
<---------------------- <------------------------------------------------------------------------ start T3103
(SDCCH)
C154, MC607
start T3124
C145A+C145C
HANDOVER ACCESS
------------------------(TCH)---------------------------->
------------------------------------------------------------->
HO DETECTION
---------------------------------->
<------------------------------------------------------------- start T3105
stop T3124
start T200
------------------------ SABM --------------------------> stop T3105
<-------------------------- UA ----------------------------- ESTABLISH INDICATION
stop T200
---------------------------------->
HANDOVER COMPLETE
HO CMP
stop T3103
-------------------------------------------------------------> ---------------------------------->
ASSIGNMENT
COMPLETE
------------------------>
Release of old SDCCH
MC151,MC717A,
MC142e
1 10 15
DR FAIL. CASES > internal DR >

success case
The same internal DR procedure
leads to an incrementation of
two sets of counters:
incoming DR counters for the

target cell: MC153, MC151,
etc.
outgoing DR counters for the
serving cell: MC144E, MC142E,
etc.
MCx counters belong to

Standard Type 110 reported
permanently
Cx counters belong to Detailed
Type 29 reported on demand
Standard type from B8

The following DR counters are provided in Type 110

for the target cell:
MC13A: TCH requests for Normal Assignment that are put into the queue,
MC153: incoming internal DR requests,
MC15A: TCH allocations for incoming internal DR,
MC151: incoming internal DR successes per cell,
MC717A: incoming internal DR successes per TRX.

for the serving cell:
MC144E: outgoing internal DR requests,
MC142E: outgoing internal DR successes,
MC607: outgoing internal+external DR attempts.

The following DR counters are provided in Type 29 (this type becomes a standard type in B8)
for the target cell:
C153: incoming internal DR requests,
C154: incoming internal DR attempts,
C151: incoming internal DR successes.

for the serving cell:
C144A: forced outgoing internal DR requests,
C144C: normal outgoing internal DR requests,
C145A: forced outgoing internal DR attempts,
C145C: normal outgoing internal DR attempts,
C142A: forced outgoing internal DR successes,
C142C: normal outgoing internal DR successes.

All the counters here and in the next slides concerning directed retry and relative to type 29 can be activated for all cells of the
BSC at once from B8. (Type 29 becomes a standard type in B8):
C142a, C142b, C142c, C142d, C143a, C143b, C143c, C143d, C143e, C143f, C143g, C143h, C144a, C144b, C144c, C144d,
C145a, C145b, C145c, C145d, C151, C152,C153,
C154,
C555
All Rights
Reserved
Alcatel-Lucent 2010
Incoming Internal DR - Failures
DR FAIL. CASES > Incoming internal DR failures:

Directed Retry procedure from the target cell point of view
DR Preparation:
congestion: no RTCH available in the target cell
does not concern the outgoing side (serving cell point of view)
DR Execution:
radio problem: the MS fails to access the new channel
the reversion/drop discrimination concerns only the serving cell
1 10 16


Incoming Internal DR - Congestion
DR FAIL. CASES > Incoming internal DR fail: congestion

MS
serving cell
MC555=C155
No free TCH
In serving cell
target cell
BSC
MSC

< ---------------------------------------------------ASSIGNMENT REQUEST
Queuing allowed
Start T11
--------------------------------------------------- >
QUEUING_INDIC.
MC13A
Standard Type
1 10 17

C155 is available in Type 29.

IDR condition met
MC153, MC144e,MC607
No free TCH
In target cell
MC555
Incoming Internal DR - Radio Failure
DR FAIL. CASES > Incoming internal DR fail: MS access problem
MS
Serving cell
Target Cell
BSC
HO CMD
HANDOVER COMMAND
<----------------------- <------------------------------------------------------------------------ start T3103
HANDOVER ACCESS
C154
------------------------------------------------------------->
------------------------------------------------------------->
HO DETECTION
---------------------------------->
<------------------------------------------------------------- start T3105
SABM
UA
---------------------------------->
<------------------------------------------------------------- stop T3105
HANDOVER COMPLETE
----------------------------------------------------- - - - -X
MS
serving cell
target cell
BSC
SABM
MEAS REP
----------------------->
----------------------->
MEASUREMENT RESULT
UA
------------------------------------------------------------------------>
------------------------------------------------------------------------>
<----------------------CHANNEL ACTIVATION
HO FAILURE
HANDOVER FAILURE
<--------------------------------------------------------> ------------------------------------------------------------------------> C152
CHANNEL ACTIV ACK
---------------------------------->
MSC
HO CMD
HANDOVER COMMAND
<----------------------- <------------------------------------------------------------------------ start T3103
C154
SABM
-----------x
T3103 expiry
C152
1 10 18

All incoming internal DR failures due to radio problems are counted in the same counter C152.
This counter is provided in Type 29
Both radio failures with Reversion Old SDCCH Channel and radio drop are counted together.

Incoming Internal DR - Counters
DR FAIL. CASES > Incoming internal DR counters

REQUEST
ATTEMPT
SUCCESS
Preparation Failure
Execution Failure
CONGESTION
INCOMING INTERNAL Directed Retry

Preparation Request
Execution
BSS PB
MC153, C153
Congestion
BSS Pb
MC555, C155
C153-C154-C155
Attempt
C154

BSS Pb
C152
C154-C151-C152
Success
MC151, C151
MS ACCESS PB
BSS PB
1 10 19
Type 29 counters become a standard (PMC)

All MCxxx counters are available in Type 110.

All Cxxx counters are available in Type 29.
Type 29 counter becomes a standard in B8.

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS
Specific indicators for densification techniques > Directed Retry > Incoming DR
DRIBCAR: efficiency of the incoming internal DR preparation = MC15A/MC153
DRIBCNR: rate of incoming internal DR failures due to congestion = MC155/MC153
DRIBEFR: efficiency of the incoming internal DR execution = MC717A/MC153
Other indicators can be computed:

from Type 110 counters:
DRIBSUR: global efficiency of incoming internal DR

= MC717A/MC153 = MC151/MC153
from Type 29 counters
rate of incoming internal DR preparation failures due to BSS problems

= (C153-C154-C155)/C153
rate of incoming internal DR execution failures due to BSS problems
= (C154-C151-C152)/C154
rate of incoming internal DR execution failures due to radio access problems
= C152/C154

Outgoing Internal DR - Failures
DR FAIL. CASES > Outgoing internal DR failures

Directed Retry procedure from the serving cell point of view
DR Preparation:
congestion on the target cell (no specific counter on the serving cell)
DR Execution:
1 10 21


Outgoing Internal DR - Radio Failure ROC
DR FAIL. CASES > Outgoing internal DR fail: reversion old channel

MS
Serving cell
Target Cell
BSC
HO CMD
HANDOVER COMMAND
<-------SDCCH----- <-----------------------------------------------------------------------HANDOVER ACCESS
----------------------TCH-------------------------------->
------------------------------------------------------------->
HO DETECTION
---------------------------------->
<------------------------------------------------------------- start T3105
SABM
UA
---------------------------------->
<------------------------------------------------------------- stop T3105
HANDOVER COMPLETE
----------------------------------------------------- - - - -X
SABM
----------------------->
UA
------------------------------------------------------------------------>
<----------------------HO FAILURE
HANDOVER FAILURE
-----------------------> ------------------------------------------------------------------------>
start T3103
MC144E
C144A or C144C
C143A or C143E
1 10 22


C144A, C143A:
Forced DR
C144C,C143E:
Normal DR
Outgoing Internal DR - Radio Failure Drop
DR FAIL. CASES > Outgoing internal DR fail: drop
MS
serving cell
target cell
BSC
M SC
HO CM D
HANDOVER CO M M AND
<----------------------- <------------------------------------------------------------------------ start T3103
M C144E
SABM
C144A or C144C
----------x
T3103 expiry
C143B or C143F
------------------------>
ASSIG NM ENT
FAILURE
Radio interface
m essage failure
Release of SDCCH and TCH
1 10 23

Counters C144A, C143B, C144C, C143F are type 29.

C144A,C143B:
Forced DR
C144C,C143F:
Normal DR
Outgoing Internal DR - Counters
DR FAIL. CASES > Outgoing internal DR counters

REQUEST
ATTEMPT
SUCCESS
Preparation Failure
Execution Failure
CONGESTION
OUTGOING INTERNAL Directed Retry

Preparation
BSS PB
Request
MC144E, C144A+C144C
(C144A+C144C) - (C145A+C145C)
Attempt
C145A+C145C
DROP RADIO

Drop radio
BSS Pb
C143A+C143E
C143B+C143F
(C145A+C145C) - (C143A+C143E+C143B+C143F)
BSS PB
Success
MC142E, C142A+C142C

Execution
1 10 24


Specific indicators for densification techniques > Directed Retry > Outgoing DR
DROBSUR: global efficiency of outgoing internal DR = MC142E/MC144E
Other indicators can be computed

efficiency of the outgoing internal DR preparation

= (C145A+C145C)/(C144A+C144C)
efficiency of the outgoing internal DR execution
= (C142A+C142C)/(C145A+C145C)
rate of outgoing internal DR execution failures due to BSS problems
= [(C145A+C145C) - (C143A+C143E+C143B+C143F)] / (C145A+C145C)
rate of outgoing internal DR execution failures due to radio problems with reversion old channel
= (C143A+C143E) / (C145A+C145C)
rate of outgoing internal DR execution failures due to radio problems with drop
= (C143B+C143F) / (C145A+C145C)
type 29 counters are defined:
DRFOSUIN
C142a
NB_OUT_FORCED_IDR_SUCC
DRFOSUEN
C142b
NB_OUT_FORCED_EDR_SUCC
DROBSUIN
C142c
NB_OUT_NOR_IDR_SUCC
DROMSUEN C142d
NB_OUT_NOR_EDR_SUCC
DRFORDIN
C144a
NB_OUT_FORCED_IDR_REQ
DRFORDEN C144b
NB_OUT_FORCED_EDR_REQ
DROBRDIN
C144c
NB_OUT_NOR_IDR_REQ
DROMRDEN C144d
NB_OUT_NOR_EDR_REQ
DROBRQIN
C145c
NB_OUT_NOR_IDR_ATPT
DROMRQEN C145d
NB_OUT_NOR_EDR_ATPT

External DR - Success
DR FAIL. CASES > External DR > successful case
MS
serving_cell
BSC
MSC
< ------ASSIGNT REQUEST------TCH request queued
------ HO_REQUIRED ---------->
EDR condition met
MC144F
BSC
----------CR (HO_REQUEST) ----->

< --------- CC -----------------------< ----- HO_REQUEST_ACK -------(HO_COMMAND)
target_cell
MS
MC820
---- CHANNEL_ACTIVATION ------>
< - CHANNEL_ACT_ACK------------Sta rt T9113
MC821
< ------------------------- HO_COMMAND -----------------------------------------------------C145B+ C145D Sta rt T8
< ---- HO_ACCESS ----< ---- HO_ACCESS ----< ------ HO_DETECTION-------------< -- HO_DETECTION --------------
--- PHYSICAL_INFO -->
< ----- ESTABLISH_INDICATION ----
Relea se of SDCCH
< ---- CLEAR_COMMAND -----MC142F Cause : HO_SUCCESSFUL

Stop T8
< --- SABM ------------------- UA -------------->
< ----------- HO_COMPLETE ---------------------------------------< --- HO_COMPLETE --------------- Stop T9113

MC642
The same external DR procedure leads to an incrementation of two sets of

counters:
incoming external HO counters for the target cell: MC820, MC821, etc.
outgoing external DR counters for the serving cell: MC144F, MC142F, etc.
1 10 26

The following DR counters are provided in Type 110 for the serving cell:
MC144F: outgoing external DR requests,
MC142F: outgoing external DR successes.
The following DR counters are provided in Type 29 for the serving cell:
C144B: forced outgoing external DR requests,
C144D: normal outgoing external DR requests,
C145B: forced outgoing external DR attempts,
C145D: normal outgoing external DR attempts,
C142B: forced outgoing external DR successes,
C142D: normal outgoing external DR successes.
As for internal DR, external DR Counters are available permanently

No counter is provided for the target cell for an external DR since an incoming DR cannot always be discriminated
from an incoming external HO. Therefore incoming external DRs are counted together with incoming external HOs in
the related counters.

Outgoing External DR - Failures
DR FAIL. CASES > Outgoing external DR failures

Directed Retry procedure from the serving cell point of view
DR Preparation:
congestion on the target cell (no specific counter on the serving cell)
DR Execution:
1 10 27


Outgoing External DR - Radio Failure ROC
DR FAIL. CASES > Outgoing external DR fail: reversion old channel
MS
serving_cell
ASSIGNT REQUEST
--------------------->
BSC
MSC
TCH request queued

---- HO_REQUIRED ------->
EDR condition met
MC144F
BSC
----------CR (HO_REQUEST) ------------------->

C145B,C143C: Forced DR
C145D,C143G: Normal DR
1 10 28
MS

C145B+ C145D
----- SABM -------->
< --- UA ------------- -- ESTABLISH_INDICATION->
----- HO_FAILURE (reversion to old channel) ------------------------------------------>
C143C+ C143G
target_cell
----- CLEAR_COMMAND ---------------------->



Outgoing External DR - Radio Failure Drop
DR FAIL. CASES > Outgoing external DR fail: drop
MS
serving_cell
ASSIGNT REQUEST
--------------------->
BSC
MSC
TCH request queued

---- HO_REQUIRED ------->
EDR condition met
MC144F
BSC
----------CR (HO_REQUEST) ------------------->

----- SABM --- X

T8 expiry ----- CLEAR_REQUEST ->
1 10 29


MS

C145B+ C145D
----- SABM --- X
----- SABM --- X
C143D+ C143H Radio interface message fail

C145B,C143D: Forced
DR
C145D,C143H: Normal DR
target_cell
Outgoing External DR - Counters
DR FAIL. CASES > Outgoing external DR counters

REQUEST
ATTEMPT
SUCCESS
Preparation Failure
Execution Failure
CONGESTION
BSS PB
OUTGOING EXTERNAL Directed Retry

Preparation
Execution
Request
MC144F, C144B+C144D
(C144B+C144D) - (C145B+C145D)
Attempt
C145B+C145D

Drop radio
BSS Pb
C143C+C143G
C143D+C143H
(C145+C145D) - (C143C+C143G+C143D+C143H)
Success
MC142F, C142B+C142D
1 10 30

DROP RADIO


BSS PB
Specific indicators for densification techniques > Directed Retry > Outgoing DR
DROMSUR: global efficiency of outgoing external DR = MC142F/MC144F
Other indicators can be computed

efficiency of the outgoing internal DR preparation

= (C145B+C145D)/(C144B+C144D)
efficiency of the outgoing internal DR execution
= (C142B+C142D)/(C145B+C145D)
rate of outgoing internal DR execution failures due to BSS problems
= [(C145B+C145D) - (C143C+C143G+C143D+C143H)] / (C145B+C145D)
rate of outgoing internal DR execution failures due to radio problems with reversion old channel
= (C143C+C143G) / (C145B+C145D)
rate of outgoing internal DR execution failures due to radio problems with drop
= (C143D+C143H) / (C145B+C145D)
Interesting indicator:
TCQUSUDSR: rate of outgoing internal and external directed retries (forced + normal) successfully performed
over all RTCH requests queued during normal assignment.

1 10 32


Signaling Links
MSC
A-Interface MT-Link signaling #7 System with SCCP
Abis Interface RSL with LAPD Protocol
BSC
BTS
BSC
Air-Interface (CCCH/SACCH/FACCH) with LAPDm Protocol
OML Link with X25 connection LAPB Protocol
1 10 33


BSC
BTS
MS
OMC-R
The Reference Model
7 Application
6 Presentation
User of Transport Service
5 Session
4 Transport
3 Network
2 Data Link
Network
Service
1 Physical
1 10 34


Transport Service
The Reference Model [cont.]
Layer 1
Physical; Responsible for the transparent transmission of information across
the physical medium (HDB3, PCM, AMI)
Layer 2
Data Link; Responsible for providing a reliable transfer between the terminal
and the network (#7, LAPD,etc.)
Layer 3
Network; responsible for setting up and maintaining the connection across a
network (CM, MM, RR, Message routing, etc.)
1 10 35


The Reference Model [cont.]
Layer 4
Transport; responsible for the control of quality of service (Layer of
information)
Layer 5
Session; Handles the coordination between the user processes (Set up
transfer of information)
Layer 6
Presentation; responsible for ensuring that the information is presented to
the eventual user in a meaningful way (Type format. Ex. ASCII)
Layer 7
Application; provides lower levels with user interface (Operating System)
1 10 36


BSS Protocol Stacks
MS
BSC
BTS
Air Intfc
Abis Intfc
MSC
B .. F Intfc
A Intfc
CM
CM
MM
MM
RR
RR
BSSAP
RR
PSTN
ISDN
BSSAP
BSSAP
SCCP
SCCP
MTP
MTP
64 kb/s
64 kb/s
LAYER 3
BTSM
LAPDm
LAPDm LAPD
digit
digit
radio
radio
1 10 37
64 kb/s
LAPD
64 kb/s


LAYER 2
LAYER 1
BSS Protocol Stacks [cont.]
(detailed)
SS (SMS)
(SMS)
SS
CC
SS (SMS)
CC
(Relay
(Relay)
MM
MM
DTAP
DTAP
BSS
MAP
RR
RR
BSS
MAP
MAP
MAP
SSGT
SSGT
SSCS
SSCS
SSCS
SSCS
SSTM 3
SSTM 3
SSTM 3
SSTM 3
SSTM 2
SSTM 2
SSTM 2
SSTM 2
PCM TS
PCM TS
3
RR'
2
LAPDm
LAPDm
Phycal
Layer
Phycal
Layer
MS
Um
BTSM
BTSM
LAPD
LAPD
64 kbit/s
or PCM
BTS
1 10 38
TS
A bis
64 kbit/s
or PCM TS
PCM TS
A
BSC


PCM TS
(D)
MSC / VLR
NSS
(ex. : HLR)
Signaling on the A Interface
Uses #7 with Signaling Connection Control Part (SCCP) with a new

Application Base Station Application Part (BSSAP). BSSAP is divided into
Direct Transfer Application Part (DTAP) and Base Station Subsystem
Management Application Part (BSSMAP)
DTAP
BSSAP
User Data
BSSMAP
SCCP
Layer 1-3
MTP 1-3
1 10 39


GSM BSS Protocols
BSSMAP
Contains the messages, which are exchanged between the BSC and the MSC
and which are evaluated from the BSC
In fact all the messages which are exchanged as RR (Radio Resource
Management Services between the MSC, BSC and MS). Also control
Information concerning the MSC and BSC
Example: Paging, HND_CMD, Reset
DTAP
Messages which are exchanged between an NSS and an MS transparent. In this
case, the BSC transfers the messages without evaluation transparent. Mainly
Messages from Mobility Management (MM) and Call Control (CC)
1 10 40


GSM BSS Protocols [cont.]
Relationship between DTAP, CC, MM, BSSMAP, RR
Call Control (CC)
MS
Radio Resource (RR)
DTAP
BSS
MSC
BSSMAP
Back
1 10 41


5 LCS
1 10 42


5 LCS
LCS Function
LCS function (linked to MC02i) and other counters
LCS allows to access the MS location provided by the BSS.
On MS request to know its own location (MC02 impacted, see the previous
slide)
On network request (especially during Emergency calls)
On external request (LCS Client)
Positioning methods provided can be:

Cell-ID or Cell-ID + TA (Timing Advance)
Conventional (standalone) GPS
Assisted GPS (with the help of A-GPS server to compute location)
MS based (MB): MS is able to perform a pre-computation
MS assisted (MA): MS sends info, Network computes
1 10 43

Assisted GPS Method:

Mobile-based: The MS performs OTD signal measurements and computes its own location estimate. In this case
the network provides the MS with the additional information such as BTS coordinates and the RTD values. These
assistance data can be either broadcast on the CBCH (using SMSCB function) or provided by the BSS in a point to
point connection (either spontaneously or on request from the MS).
Mobile-assisted: The MS performs and reports OTD signal measurements to the network and the network
computes the MS location estimate.
With
OTD: Observed Time Difference: the time interval that is observed by an MS between the receptions of
signals (bursts) from two different BTSs.
RTD: Real Time Difference: This means the relative synchronization difference in the network between two
BTSs.
Finally, 4 methods are possible for positioning:
Cell ID+ TA
Conventional (MS equipped with GPS System)
A-GPS MS Based
A-GPS MS Assisted
These 4 Methods induce a set of counters (2 per method) to give the average latitude and longitude of mobiles in
the cell.
These counters are located in the MFS and can be used in RNO (cartographic part).

5 LCS
LCS Function: Architecture
Where is the accident?
Emergency call
Where am I?
BTS
MSC
Abis
Lg
GMLC
BSC
MS
Abis
SMLC
BTS
SAGI
MFS
1 MS Request
2 Network Request
3 External Request
External
LCS client
Where is my son?
3
Lh
A-GPS
server
SMLC function integrated in MFS:

- receives the loc. Request from the GMLC through the
MSC/BSC
- Schedules all the necessary actions to get MS location
- Computes MS location
- Provides the result back to the GMLC
1 10 44
OSP
GPS
reference
network
Lb
Le
HLR
LCS: Location Services

SMLC: Serving Mobile Location Center
GMLC: Gateway Mobile Location Center
A-GPS: Assisted GPS

In case of MS requests for its location, MC02 is impacted:

MC02i = Number of Mobile Originating SDCCH establishments for LCS purposes.
In all cases, some counters related to LCS provide specific information (attempts, success, failures)
See the next slide.

5 LCS
Example
Mobile terminated location request failure / success (External request)

BTS
MS
BSC
SMLC
MSC
GMLC
HLR
LCS Client
LCS Service Request

Send_Routing_Info rqst
Send_Routing_Info resp
Provide_Subscriber_Location
Paging
Authentication + Ciphering
BSSMAP Perform_Location_Request
MC923a
BSSAP-LE Perform_Location_Request
Adequat positionning method chosen by SMLC
MC923c
Failure
BSSAP-LE Perform_Location_Response (failure)

BSSMAP Perform_Location_Response (failure)
MC923d
BSSMAP Perform_Location_Abort
BSSAP-LE Perform_Location_Response
Success
MC923b
BSSMAP Perform_Location_Response
Provide_Subscriber_Location Result
BSSMAP Clear Command and Release
1 10 45
LCS Service Response

Four counters
MC923a
NB_LCS_REQ
Number of location requests received from the MSC in CS domain.
MC923b
NB_LCS_SUCC
Number of successful location requests performed in a BSS.
MC923c
NB_LCS_FAIL_LB Number of location requests rejected by the SMLC.
MC923d
NB_LCS_ABORT
Number of location aborts received from the MSC in CS domain.
Calculated indicators based on BSC counters:
Number of failures on LCS requests due to BSS problem,
Rate of LCS requests aborted,
Rate of successes on LCS requests,
Rate of failures on LCS requests,
Rate of SDCCH seizures for Location Services.
Other counters in SMLC (MFS) provide details by type of positioning (CI+TA, Conventional GPS, MS-Assisted A-GPS, MSBased A-GPS) and for different Error causes.
See the next slide.

LCS Counters in MFS:

QOS FOLLOW UP:
P800: NB_LOC_REQ
Number of received LCS requests for MS positioning received from the

BSC
P801: NB_ASSIST_DATA_REQ
Number of received LCS requests for GPS assistance data (initially
requested by the MS) received from the BSC.
P802: NB_ASSIST_DATA_SUCC
Number of successful GPS assistance data delivery (initially requested
by the MS) responses sent to the BSC.
P803: NB_LOC_TA_SUCC
Number of successful location responses sent to the BSC using TA
positioning method.
P804: NB_LOC_CONV_GPS_SUCC
Number of successful location responses sent to the BSC using
Conventional GPS positioning method.
P805: NB_LOC_MA_AGPS_SUCC
Number of successful location responses sent to the BSC using MSAssisted A-GPS positioning method.
P806: NB_LOC_MB_AGPS_SUCC
Number of successful location response sent to the BSC using MS-Based
A-GPS positioning method.
P807: NB_LOC_TA_PCF_REQ
Number of location calculation attempts with TA positioning PCF.
P808: NB_LOC_TA_PCF_SUCC
Number of location calculations successfully performed with TA
positioning PCF.
P809: NB_LOC_CONV_GPS_PCF_REQ
Number of location calculation attempts with Conventional GPS PCF.
P810: NB_LOC_MA_AGPS_PCF_REQ
Number of location calculation attempts with MS-Assisted A-GPS PCF.
P811: NB_LOC_MA_AGPS_PCF_SUCC
Number of location calculations successfully performed with MS
Assisted A-GPS PCF.
P812: NB_LOC_MB_AGPS_PCF_REQ
Number of location calculation attempts with MS-Based A-GPS PCF.
P813: NB_LOC_MB_AGPS_PCF_SUCC
Number of location calculations successfully performed with MS-Based
A-GPS.
P814: NB_LCS_PROTOCOL_ERROR
Number of failed LCS procedures due to LCS protocol error.
P815: NB_LCS_INTERRUPTED_INTRA_BSC_HO Number of failed LCS procedures due to intra-BSC handover.
P816: NB_LCS_INTERRUPTED_INTER_BSC_HO Number of failed LCS procedures due to inter-BSC handover.
P817: NB_LCS_FAILURE_RRLP
Number of failed LCS procedures due to RRLP problem.
P818: NB_LCS_FAILURE_TIMER_EXPIRY
Number of failed LCS procedures due to LCS guard timer expiry.
P819: NB_LCS_FAILURE_INTERNAL
Number of failed LCS procedures due internal problem detected by
the MFS/SMLC.
P820: NB_UNKNOWN_LCS_REQ
Number of LCS requests rejected because not supported by the SMLC.
P821: NB_LOC_CONV_GPS_PCF_SUCC
Number of location calculations successfully performed with Conventional
GPS PCF.

PCF: Positioning Calculation Function

POSITION AVERAGE USED ON RNO: Values are given in minutes
LATITUDES AND LONGITUDES:
P822: AV_TA_LAT
Average of latitudes for TA Method
P823: AV_TA_LONG
Average of longitudes for TA Method
P824: AV_CONV_GPS_LAT
Average of latitudes for Conventional GPS Method
P825: AV_CONV_GPS_LONG
Average of latitudes for Conventional GPS Method
P826: AV_MA_AGPS_LAT
Average of latitudes for MS-Assisted A-GPS Method
P827: AV_MA_AGPS_LONG
Average of longitudes for MS-Assisted A-GPS Method
P828: AV_MB_AGPS_LAT
Average of latitudes for MS-Assisted A-GPS Method
P829: AV_MB_AGPS_LONG
Average of longitudes for MS-Based A-GPS Method
STANDARD DEVIATION:
standard deviation is a measure of the dispersion around the average point
P830: ST_DEV_TA_LAT
Standard deviation of the latitude of MS obtained with TA Method
P831: ST_DEV_TA_LONG
Standard deviation of the longitude of MS obtained with TA Method
P832: ST_DEV_CONV_GPS_LAT
Standard deviation of the latitude of MS obtained with Conventional
GPS Method
P833: ST_DEV_CONV_GPS_LONG
Standard deviation of the longitude of MS obtained with
Conventional GPS Method
P834: ST_DEV_MA_AGPS_LAT
Standard deviation of the latitude of MS obtained with MS Assisted
A-GPS Method
P835: ST_DEV_MA_AGPS_LONG
Standard deviation of the longitude of MS obtained with MS Assisted
A-GPS Method
P836: ST_DEV_MB_AGPS_LAT
Standard deviation of the latitude of MS obtained with MS Assisted
A-GPS Method
P837: ST_DEV_MB_AGPS_LONG
Standard deviation of the longitude of MS obtained with MS Assisted
A-GPS Method

5 LCS
Definitions
New end-user services which provide the geographical location of an

MS:
On MS request to know its own location
On network request (especially during Emergency calls)
On external request (LCS Client)
Several positioning methods:

Cell-ID or Cell-ID + TA (Timing Advance)
Conventional (standalone) GPS
Assisted GPS (with A-GPS server help to compute location)
MS-based (MB): the MS is able to perform a pre-computation
MS-assisted (MA): the MS sends info, Network computes
1 10 48

Assisted GPS Method:
Mobile-based: The MS performs OTD signal measurements and computes its own location estimate. In this case, the
network provides the MS with the additional information such as BTS coordinates and the RTD values. These
assistance data can be either broadcast on the CBCH (using SMSCB function) or provided by the BSS in a point-topoint connection (either spontaneously or on request from the MS).
Mobile-assisted: The MS performs and reports OTD signal measurements to the network and the network computes
the MSs location estimate.
With
OTD: Observed Time Difference: the time interval that is observed by an MS between the receptions of signals
(bursts) from two different BTSs.
RTD: Real Time Difference: This means the relative synchronization difference in the network between two BTSs.
Finally, 4 methods are possible for positioning:
Cell ID+ TA,

This is the simplest method for determining the location of a mobile. It relies on the hypothesis that the
geographical coverage of a cell corresponds to that predicted by radio coverage studies. When an active mobile is
connected to a base station, the mobile is assumed to be located geographically within the area predicted to be
best served by this base station
Conventional (MS equipped with GPS System),
MS-based Assisted GPS,
MS-Assisted GPS.

5 LCS
LCS Architecture
1 MS Request
2 Network Request
3 External Request
Where is
the accident?
Where is
my son?
Abis
Emergency call
Where
am I?
BTS
Lg
MSC
BSC
A-GPS : Assisted GPS

GMLC : Gateway Mobile Location Center
LCS : Location Services
SMLC : Serving Mobile Location Center
OSP
Le
External
LCS client
GMLC
Abis
Lh
BTS
Lb
SMLC function integrated in MFS:

- receives the location request from
the GMLC through the MSC/BSC
- schedules all the necessary actions
to get MS location
- computes MS location
- provides the result back to the GMLC
MFS
HLR
SAGI
SMLC
A-GPS
server
1 10 49
GPS receivers
reference network


5 LCS
LCS Positioning Procedure
Provide
subscriber location
5
BTS
BSC
BTS
Paging,
authentication,
ciphering,
notification
4
6
Individual
positioning
MSC
Provide
subscriber
location
3
Location report
OSP
GMLC
2
Routing
information
MFS
Location
request
1
8
Location
response
HLR
SMLC
1 10 50

If the MS is in idle mode, the MSC first performs a CS paging, authentication and ciphering in order to establish an
SDCCH with the MS. The MS subscriber is not aware of it, i.e. no ringing tone, except towards GPRS MS in Packet
Transfer Mode which may suspend its GPRS traffic in order to answer to the CS Paging (i.e. not fully transparent
for the subscriber).
When the MS is in dedicated mode (after a specific SDCCH establishment for location, or during an on-going call),
the MSC sends the location request to BSC in the existing SCCP connection for the current call, which forwards it
to the SMLC.

5 LCS
LCS Protocol
Signaling Protocols between the MS (CS domain) and the SMLC
SMLC
(MFS)
BSC
Target MS
RRLP
(04.31)
RRLP
(04.31)
Relay
RR
(04.18)
BSSLAP
BSSLAP
(08.71)
BSSAP-LE
BSSAP-LE
(09.31)
RR
L2
(LAPDm)
L2
(LAPDm)
L2-GSL
L2-GSL
L1
L1
L1-GSL
L1-GSL
Um
1 10 51
Lb


5 LCS
LCS Protocol [cont.]
Example: Mobile terminated location request success (External request)

MS
BTS
BSC
SMLC
MSC
GMLC
HLR
LCS client
LCS Service Request

Send_Routing_Info request
Send_Routing_Info response
Paging
Starts
T_Location
Adequate positioning method
chosen by SMLC with
optional additional scenario
BSSMAP Perform_Location_Response
Stop
T_Location
Provide_Subscriber_Location Result
LCS Service Response
MSSMAP Clear Command and Release
1 10 52

T_location_Longer used in case of optional additional scenario (see graph):

Upon receipt of the MS POSITION COMMAND message from the SMLC (optional additional scenario), the BSC stops the
T_Location timer, and starts instead the T_Location_Longer timer. This timer is stopped only at the end of the location
procedure in the BSC, i.e. when an 08.08 PERFORM LOCATION RESPONSE message is sent back to the MSC.
Aborts:
Abort by MSC
Depending on the location procedure and its current state of execution, upon PERFORM LOCATION ABORT message receipt, the
BSC sends immediately to the MSC a PERFORM LOCATION RESPONSE message (when no exchange on the Lb interface is ongoing), or to the SMLC either a PERFORM LOCATION ABORT or an ABORT message. The BSC starts the timer T_Loc_abort to
supervise the SMLC response.
Abort by BSS
The BSC must send either a PERFORM LOCATION ABORT message or a ABORT message to the SMLC and starts the timer
T_Loc_abort if an ongoing location request is interrupted at the BSC level for the following reasons:
by an inter-BSC handover, or
if the main signaling link to the target MS is lost or released, or
the SCCP connection on the A interface is released, or
if the timer T_Location expires.
The useful B8 content of the received PERFORM LOCATION REQUEST message is:
Location type,
Classmark information 3,
Requested QoS: provides service requirement concerning geographic positioning and response time
Current Cell Id + TA information are always provided to the SMLC.
accuracy, the response time category (Low Delay or Delay Tolerant),
Rights
Reserved
Alcatel-Lucent
2010
The time of transfer of the assitance data onAll
the
SDCCH
is estimated
about 14s
for a 1000 octets information.
5 LCS
Principles of CI + TA Positioning Method

LCS_LATITUDE
HALFP
3dB point
given by the azimuth
and the HPBW
WR
_B
EA
M
_W
TH
ID
LCS_AZIMUTH
(Main Beam Direction
given by the azimuth)
MS
estimated location
TA
LCS_LONGITUDE
g
in
Serv
553
ce
ll (
CI)
1 10 53
3dB point
given by the azimuth
and the HPBW

With the TA positioning method, no signaling exchange is required between the SMLC and the MS (i.e. RRLP protocol is not
required). The TA positioning method is applicable to all the MSs (supporting LCS or not).
Based on:
Cell Identity (CI) of the serving cell.
Timing Advance (TA) value reported by MS:
intersection point of a line from the BTS antenna in their main direction with a circle which radius is corresponding with
the propagation delay (timing advance) is the MS estimated position.
Omni-directional cells: MS position = site position.
Parameters:
EN_LCS flag to enable/disable the Location Services per BSS
0 = Enabled; 1= Disabled; Default = 0
IF EN_LCS=1, CI+TA method is enabled in all the BSS cells
LCS_LATITUDE: Latitude of the BTS supporting the cell
LCS_LONGITUDE: Longitude of the BTS supporting the cell
LCS_AZIMUTH: Antenna direction orientation for the sector supporting the cell
HALFPWR_BEAM_WIDTH: Antenna half power beamwidth for the sector supporting the cell
Optimization parameters:
ARC_SIZE_FACTOR: Factor used in the computation of the width in degree of the ellipsoid arc returned by the MFS when
computing location estimate based on TA positioning method.
MIN_RADIUS_FACTOR: Factor used in the computation of the minimum radius of the ellipsoid arc returned by the MFS when
computing location estimate based on TA positioning method
MAX_RADIUS_FACTOR :Factor used in the computation of the maximum radius of the ellipsoid arc returned by the MFS when
computing location estimate based on TA positioning
All Rights method
Reserved Alcatel-Lucent 2010
5 LCS
Positioning Methods: Conventional GPS
Conventional GPS location procedure

This optional location procedure is chosen by the SMLC (if the MS supports
it) upon reception of a Perform Location Request message from the BSC
MS
BTS
BSC
SMLC
Perform
Location
Request
Location
Request
(X,Y)
Measurement Position Request
Measurement Position Response (X,Y)
Location
Response
(X,Y):
computed position
1 10 54
Perform
Location
Response (X,Y)

The MS continuously computes its position

The terminal searches for satellites, acquires all the GPS data, computes its own position and finally provides the
location estimation to the SMLC

5 LCS
Positioning Method: Assisted GPS Positioning
Assisted GPS Positioning Method (A-GPS)

Assistance GPS Positioning Method is split into:
MS Based A-GPS method
MS Assisted A-GPS method
Assistance data on request

- GPS acquisition assistance
- Navigation model
(almanac, ephemeris)
- Ionospheric model
- Time integrity
GPS MS
1 10 55
A-GPS
server
GPS receivers
reference network

Assistance data gathered from a GPS reference network receiver is broadcast to the GPS MS.
Flags/Parameters
EN_LCS = 1
EN_MS_BASED_AGPS enables/disables the positioning method MS Based A-GPS per CELL
0 = disabled; 1 = enabled; default = 0
EN_MS_ASSISTED_AGPS enables/disables the positioning method MS Assisted A-GPS per CELL
0 = disabled; 1 = enabled; default = 0

5 LCS
Positioning Method: Assisted GPS Positioning [cont.]
A-GPS location procedure / MS Based A-GPS

MS
BTS
BSC
Perform
Location
Request
GPS info
Request
GPS info
Response
Location
Request
Assistance Data
Assistance
Data
Positioning calculation:
latitude, longitude
and altitude
A-GPS
Server
SMLC
Assistance Data Acknowledge
Position
Request
Measurement Position Response (X,Y)
(X,Y)
Position
Response
Location
Response
Perform
Location
Response (X,Y)
(X,Y):
computed position
1 10 56

Using assistance data, the MS computes by itself the position and sends it back to the SMLC.

5 LCS
Positioning Method: Assisted GPS Positioning [cont.]
A-GPS location procedure / MS Assisted A-GPS

MS
BTS
BSC
Perform
Location
Request
GPS info
Request
GPS info
Response
Location
Request
Assistance Data
Assistance
Data
Pseudo-range
measurements (M)
A-GPS
Server
SMLC
Assistance Data Acknowledge
Position
Request
Position
Response
Measurement Position Response (M)
GPS Location
Request (M)
Location
Response
Perform
Location
Response (X,Y)
(X,Y):
computed position
1 10 57
GPS Location
Response (X,Y)
(X,Y)

Using a reduced set of assistance data, the MS makes pseudorange measurements and sends the result to the AGPS server, which fixes the position in the end.

5 LCS
LCS Impact on HO
HO preparation
Inhibition of better cell handovers
Other HO
MS
BTS
BSC
SMLC
MSC
GMLC
HLR
LCS client
LCS Service Request

Send_Routing_Info request
Send_Routing_Info response
Paging
Starts
T_Location
Emergency
HO
detection
BSSLAP - Reset
1 10 58

HO needed during LCS procedure.

5 LCS
LCS Impact on HO [cont.]
HO management
Internal HO
MS
BTS
BSC
SMLC
MSC
GMLC
HLR
Intra BSC
HO
on going
BSSLAP - Reset
HO
complete
BSSMAP perform location response (cause = "Intra-BSC Handover Complete)
1 10 59

Mobile in communication

LCS client
5 LCS
LCS Impact on HO [cont.]
HO management
External HO
MS
BTS
Serving BSC
External
BSC HO
SMLC
MSC
GMLC
BSSMAP HO required
BSSAP-LE Perform_Location_Abort
1 10 60


HLR
LCS client
5 LCS
BSS Parameters
FLAGS
OPTIMIZATION DATA
Timers
EN_LCS
ARC_SIZE_FACTOR
T_Location
EN_SAGI
MIN_RADIUS_FACTOR
T_Location_longer
MAX_RADIUS_FACTOR
T_Loc_Abort
T_LCS_delay_tolerant
T_LCS_LowDelay
T_RRLP_low_delay
T_RRLP_delay_tolerant
1 10 61

BSS PARAMETERS
EN_LCS (BSC): Flag which enables or disables the LCS feature in the BSS.
EN_SAGI: Flag indicating whether SAGI is configured or not for this BSS.
T_Location: BSC timer on a per call basis to guard the response from the SMLC in case of Location Request, when
no RRLP exchange is triggered with the MS.
T_Location_longer: BSC timer on a per call basis to guard the response from the SMLC in case of Location Request,
when an RRLP exchange is triggered with the MS. Replace T_Location timer in case of Conventional GPS, MSAssisted A-GPS, MS-Based A-GPS.
T_Loc_Abort: BSC timer to guard the response from the SMLC in case of Location Abort.
T_LCS_LowDelay: SMLC timer to guard the calculation of the MS position (including the RRLP message exchange
with the target MS) in case of a Low Delay Location Request.
T_LCS_DelayTolerant: SMLC timer to guard the calculation of the MS position (including the RRLP message
exchange with the target MS) in case of a Delay Tolerant Location Request.
T_LCS_LowDelay: SMLC timer to guard the calculation of the MS position (including the RRLP message exchange
with the target MS) in case of a Low Delay Location Request.
T_RRLP_Low_delay: Timer to guard the RRLP exchange between the SMLC and the MS .
T_RRLP_delay_tolerant: Timer to guard the RRLP exchange between the SMLC and the MS.
Optimization data:
ARC_SIZE_FACTOR: Factor used in the computation of the width in degree of the ellipsoid arc returned by the MFS
when computing location estimate based on TA positioning method.
MIN_RADIUS_FACTOR: Factor used in the computation of the minimum radius of the ellipsoid arc returned by the
MFS when computing location estimate based on TA positioning method
MAX_RADIUS_FACTOR: Factor used in the computation of the maximum radius of the ellipsoid arc returned by the
MFS when computing location estimate based on TA positioning method

5 LCS
Cell Parameters
FLAGS
SITE DATA
EN_CONV_GPS
LCS_LATITUDE
EN_MS_ASSISTED_AGPS
LCS_LONGITUDE
EN_MS_BASED_AGPS
LCS_SIGNIFICANT_GC
LCS_AZIMUTH
HALF_POWER_BANDWIDTH
1 10 62

CELL PARAMETERS
EN_CONV_GPS: Flag to enable/disable the Conventional GPS positioning method.
EN_MS_ASSISTED_AGPS: Flag to enable/disable the MS Assisted A-GPS positioning method.
EN_MS_BASED_AGPS: Flag to enable/disable the MS Based A-GPS positioning method.
LCS_LATITUDE: Latitude of the BTS supporting the cell (used by the MFS to compute location estimate based on TA
positioning method).
LCS_LONGITUDE: Longitude of the BTS supporting the cell (used by the MFS to compute location estimate based on
TA positioning method).
LCS_SIGNIFICANT_GC: Indicates whether latitude and longitude are significant or not
LCS_AZIMUTH: Antenna direction orientation for the sector supporting the cell (used by the MFS to compute
location estimate based on TA positioning method).
HALF_POWER_BANDWIDTH: Half power beam width of the antenna for the sector supporting the cell (used by the
MFS to compute location estimate based on TA positioning method).
Remark: To have LCS supported for a cell, the operator must activate LCS on the BSS handling this cell but he must
also activate GPRS for this cell (i.e. setting of MAX_PDCH to a value > 0, the cell being kept locked for GPRS if the
operator does not want to have GPRS running on this cell) and configure all the required transmission resources (Ater
and Gb resources) on the GPU(s) connected to this BSC.

5 LCS
Exercise
Where is implemented the SMLC function?

What are the LCS impacts on cell dimensioning?
Time allowed:
10 minutes
1 10 63


5 LCS
Ellipsoid arc definition:

North
Point (O)
g
vin
Ser
Point (O)= serving BTS site coordinate

= serving cell antenna azimuth - /2
=A*width of serving cell sector in [],
calculated from bisector angles
of co-sited antenna azimuths
r1= inner radius of
TA ring-(B-0.5)*554 in [m]
R2=(B+C)*554 in [m]
A: ARC_SIZE_FACTOR
B: MIN_RADIUS_FACTOR
C: MAX_RADIUS_FACTOR
r1
ce
ll (
CI)
r2
Back
1 10 64

An ellipsoid arc is a shape characterized by the co-ordinates of an ellipsoid point o (the origin), inner radius r1,
uncertainty radius r2, both radii being geodesic distances over the surface of the ellipsoid, the offset angle ()
between the first defining radius of the ellipsoid arc and North, and the included angle () being the angle
between the first and second defining radii. The offset angle is within the range of 0 to 359,999 while the
included angle is within the range from 0,0001 to 360. This is to be able to describe a full circle, 0 to 360
For CI+TA method which is default one, the answer is given by description of "ellipsoid arc".
Optimization parameters:
ARC_SIZE_FACTOR: Factor used in the computation of the width in degree of the ellipsoid arc returned by the
MFS when computing location estimate based on TA positioning method.
MIN_RADIUS_FACTOR: Factor used in the computation of the minimum radius of the ellipsoid arc returned by the
MFS when computing location estimate based on TA positioning method.
MAX_RADIUS_FACTOR: Factor used in the computation of the maximum radius of the ellipsoid arc returned by
the MFS when computing location estimate based on TA positioning method.

6 Counters on Electromagnetic Emission

(EME)
1 10 65


Characteristics of the Feature
The goal of this feature is to make easier evaluating power issues in

BTSs
Recording of power emission of BTS per cell and frequency band
Triggering of warning reports based on threshold fixed by the operator

to get the real emission of antennas (at BTS antenna output port)
Take care of Environmental regulations
OMC-R
BSC
BTS
1 10 66


Characteristics of the Feature [cont.]
GSM antennas are widely in living and working places

Lack of information provided to people on their exposure to EM fields
and the risks they are running
People concerned about their health, risk of complaints
Some European directives/recommendations
are already applicable or will be very soon
1 10 67



Characteristics of the Feature [cont.]
2 new counters (Hourly from NPA for RNO reports)

EME_PWR_GSM (850/900) (Short Name: E01)
EME_PWR_DCS (1800/1900) (Short Name: E02)
Power with 0.1 Watt steps
Performance Measurement type

New Type: Type 33
Permanent type (PMC) with a fixed accumulation period: 1 hour
Counters available in MPM and NPA
Back
1 10 68

Measurements:
Only with Evolium BTS
DL power data are collected by each TRE for each band (2 considered bands: 850/900 and 1800/1900)
Recording of power effectively transmitted to the antenna in Watt
Power control, DTX and unused TS are taken into account
Loss due to stages (Any, AN) and cables between TRE output and BTS antenna output connector taken into
account
Measurements averaged every hour per cell and per frequency band
2 new cell parameters: threshold values
EME_PWR_MAX_GSM (frequency band 850/900)
EME_PWR_MAX_DCS (frequency band 1800/1900)
Possible massively updated through an OMC Java script

7 B8 Improvements
1 10 69


7 B8 Improvements
Summary
Location Services (LCS)

SDCCH Dynamic allocation
Counters Improvement
Inter PLMN HO
3G to 2G HO (and 2G to 2G only)
Dual band HO (New type: 32)
LapD congestion counter
QOS Follow-up
TCH assignment failure BSS PB now detailed
HO Attempts for Fast Traffic added in type 110
AMR counters added in type 110
MS penetration (per speech version and channel type) was type 1 counters now available in type
110
HO Causes: type 26 extended from 1 to 40 cells
Directed retry: type 29 becomes a standard (for PMC)
1 10 70


8 B9 Improvements
1 10 71


8 B9 Improvements
Summary
Type 31: New RMS counters
For AMR monitoring

For Timing Advance analysis
For BTS Power level
Type 33: Power at the BTS for Electromagnetic Environment

Monitoring (EME) (Annex 6)
Type 110: more counters for UMTS to GSM handover monitoring
The new counters were introduced in MC922 family
2 New counters for HO Cause 30: PS return to CS Zone
1 10 72


1 10 73


Purpose
SDCCH/8 time slots can be dynamically allocated on demand on a cellby-cell basis.

Dynamic SDCCH/8 time slots.
Static SDCCH time slots
Allocated
Dynamic SDCCH/8
timeslots
Max
Min
TCH Capacity
Static SDCCH
timeslots
1 10 74

Definitions
A Static SDCCH timeslot is a physical timeslot fixed allocated on the air interface. It contains 3, 4, 7 or 8 SDCCH subchannels depending on whether the timeslot is an SDCCH/3, SDCCH/4, SDCCH/7, or SDCCH/8 timeslot.

Principle
Principles
Too few SDCCH time slots could result in high blocking rate on SDCCH
(Configuration 1)
Too many SDCCH time slots could lead to a lack of TCH resources
(Configuration 2)
Configuration 1
Configuration 2
SDCCH
time slots
SDCCH
time slots
TCH Capacity
TCH Capacity
TCH
CAPACITY
Low signaling capacity
High signaling capacity
More TCH capacity
Less TCH capacity
1 10 75

Definition
An SDCCH is a logical SDCCH sub-channel mapped on a Static SDCCH timeslot or a Dynamic SDCCH/8 timeslot.
Signaling Load Cases
Timeslot split between signaling and traffic channels depends on the network signaling load. The main cases are:
Normal signaling load cells: Rural area cells in center of Location Areas (e.g. 1 SDCCH timeslot for a 3-TRX cell)
High signaling load cells:
Urban or suburban area cells in the center of a Location Area
Rural area cells at the border of Location Areas
(e.g. 2 SDCCH time slots for a 3-TRX cell)
Very high signaling load cells:
Urban or suburban area cells at the border of a Location Area
Cells with high SMS load (more than one SMS per call)
(e.g. 3 SDCCH time slots for a 3-TRX cell)

Principle [cont.]
Allocation and de-allocation of Dynamic SDCCH/8 time slots

An additional dynamic SDCCH/8 timeslot is allocated by the BSC if there is no
SDCCH sub-channel free in the cell.
A dynamic SDCCH/8 timeslot is de-allocated by the BSC after
T_DYN_SDCCH_HOLD (10s) delay if all of its SDCCH sub-channels become free
Allocation of
Dynamic SDCCH/8
times slots
BCC: BCCH
SDC : Static SDCCH
SDD : Dynamic SDCCH
Cell
BCC
BCC
SDC
SDC
TCH
TCH
TCH
TCH
TCH
TCH
SDD
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
SDD
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
1 10 76

The location of the Dynamic SDCCH/8 time slots are fixed by O&M configuration.

TIMESLOT Types
NEW TIMESLOT TYPES
SDCCH
Pure SDCCH or static SDCCH
TCH
Pure TCH
TCH/SDCCH
dynamic SDCCH
TCH/SPDCH
MPDCH
1 10 77

The OMC-R provides the BSC with the following O&M type of radio timeslots:
Main BCCH timeslot (BCC): It is a timeslot carrying FCCH + SCH + BCCH + CCCH.
Main combined BCCH timeslot (CBC): It is a timeslot carrying FCCH + SCH + BCCH + CCCH + SDCCH/4 + SACCH/4.
Static SDCCH timeslot (SDC): It is a timeslot carrying SDCCH/8 + SACCH/8.
Dynamic SDCCH/8 timeslot (SDD): It is a timeslot carrying TCH + SACCH or SDCCH/8 + SACCH/8
TCH timeslot (TCH): It is a timeslot carrying TCH + SACCH or PDCH
From RAM point of view, a radio timeslot can be defined as:

Pure BCCH timeslot: The BCCH timeslot is the radio timeslot configured as BCC by O&M. Such a timeslot only carries common CS
signalling.
Pure SDCCH timeslot: A pure SDCCH timeslot is a timeslot configured as a CBC or SDC by O&M. Such a timeslot can carry SDCCH traffic.
Pure TCH timeslot: A pure TCH timeslot is a timeslot configured as TCH by O&M. Such a timeslot only carries TCH traffic.
TCH/SDCCH timeslot: A TCH/SDCCH timeslot is a timeslot configured as SDD by O&M. Such a timeslot is dynamically allocated as TCH or
as SDCCH depending on the usage of the timeslot. It can carry TCH traffic or SDCCH traffic.
TCH/SPDCH timeslot: A TCH/SPDCH timeslot is a timeslot configured as TCH by O&M. Such a timeslot is dynamically allocated as TCH or
as SPDCH depending on the usage of the timeslot. It can carry TCH traffic or PS traffic.
MPDCH timeslot: A MPDCH timeslot is a timeslot configured as TCH by O&M. Such a timeslot can only carry common PS signalling.
A pure SDCCH timeslot can carry x SDCCH sub-channels where x equal to:
4 in case of combined CCCH and when CBCH is not configured on the timeslot,
7 in case of non-combined CCCH and when CBCH is configured on the timeslot,
3 in case of combined CCCH and when CBCH is configured on the timeslot,
8 for a normal SDCCH timeslot.
When allocated as SDCCH, a TCH/SDCCH timeslot can carry up to 8 SDCCH sub-channels.

Allocation Algorithm
SDCCH Request
SDCCH mapped on "TCU very high load state" removal
No
Yes
Are they any free SDCCH sub-channel

among Static SDCCH timeslots?
Selection of one
SDCCH sub-channel
No
Yes
Are they any free SDCCH sub-channel

among Dynamic SDCCH/8 already allocated?
Selection one
SDCCH sub-channel
Yes
No
Are they any Dynamic SDCCH/8 timeslots

available and free in the cell?
Allocate one Dynamic
SDCCH/8 timeslot
1 10 78
SDCCH Request
rejected!!!

Principle 1: Preference is given to pure SDCCH timeslots

Principle 2: Balance TCU processor load between different TCUs
In fact before entering in this algorithm (see slide) the first step is: Removal of all the SDCCH subchannels
mapped on TCU in Very High Overload state
Principle 3: FR TRX preference

SDCCH Sub-Channel Selection
Pure SDCCH Timeslot

TS with LOWEST TCU LOAD
TS with MAXIMUM FREE SDCCH Sub channels
TS with lowest index on TRX with lowest TRX_ID
TCH/SDCCH TS allocated as SDCCH

TS on FR TRX
TCH/SDCCH TS allocated as TCH

TS with LOWEST TCU LOAD
TS on FR TRX
1 10 79

Note that an SDCCH request can not access the timeslots reserved by NUM_TCH_EGNCY_HO. If all remaining
TCH/SDCCH timeslots are reserved by NUM_TCH_EGNCY_HO, then the SDCCH request shall be rejected.

Deallocation Algorithm
GENERAL CASE:
all SDCCH sub-channels of a TCH/SDCCH timeslot become back free.
the T_DYN_SDCCH_HOLD timer (10s, not tunable) is started.
If the timeslot is still free of SDCCH sub-channel when the timer expires, it is
de-allocated (it becomes back TCH).
SPECIAL CASE:
several TCH/SDCCH timeslots are allocated as SDCCH
one of them becomes free of SDCCH sub-channels. Its timer starts.
a subsequent one becomes free of SDCCH sub-channels too before expiration
of the first ones timer (10s).
one of them is immediately de-allocated (the one with lowest priority: see
previous slide in reverse order) and becomes back TCH.
For the last one, its timer is restarted (it will be de-allocated in 10s)
1 10 80

The de-allocation algorithm ensures that:
TCH/SDCCH timeslots are not allocated too fast to TCH after de-allocating them
TCH/SDCCH timeslots are not re-allocated too frequently to SDCCH
Note: while T_DYN_SDCCH_HOLD is running:
the dynamic SDCCH/8 timeslot marked as HOLD is still considered as allocated to SDCCH (and can not be
allocated to TCH);
if a subsequent dynamic SDCCH/8 timeslot (used as SDCCH and in the same cell) becomes free:
a) If this just freed dynamic SDCCH/8 timeslot has a higher priority, T_DYN_SDCCH_HOLD is re-started
and precedent dynamic SDCCH/8 timeslot in HOLD state is de-allocated immediately;
b) If this just freed dynamic SDCCH/8 timeslot has lower priority, and T_DYN_SDCCH_HOLD is re-started
and the just freed dynamic SDCCH/8 timeslot is de-allocated immediately.

O&M Configuration
Selection of static or dynamic

SDCCH
Timeslot configuration menu
Massive modification by
script
10 templates
Template customization
Template launched through
PRC
10
3
2
BTS
1
BTS
5
BTS
11
6
9
BTS
12
1 10 81

Dynamic SDCCH Rules
The CBCH must be configured on a static SDCCH/8 or SDCCH/4 timeslot.
Combined SDCCHs (SDCCH/4 + BCCH) are always static.
To avoid incoherent allocation strategy between SDCCH and PDCH, a dynamic SDCCH/8 timeslot cannot
have the characteristic of being a PDCH (it cannot carry GPRS traffic).
The operator must configure at least one static SDCCH/8 or SDCCH/4 timeslot on BCCH TRX in a cell.
In cells with E-GSM, only the TRX, which does not belong to the G1 band, can support dynamic and static
SDCCHs.
In multiband and concentric cells, only the TRX, which belongs to the outer zone, can support dynamic and
static SDCCHs.
Up to 24 static/dynamic SDCCH sub-channels can be configured per TRX.

O&M configuration [cont.]
Default configuration for a cell which has only Full rate TRX
Number of TRX
in the cell
Number of
Static SDCCH
Number of
Dynamic SDCCH
Total number
of SDCCH
Maximum
SDCCH/TRX
ratio
Is BCCH/CCCH
combined with
SDCCH?
12
12.0 (note 1)
Yes
12
6.0
Yes
16
24
12.0
No
3
4
8
8
16
24
24
32
8.0
8.0
No
No
24
32
6.4
No
24
32
5.3
No
16
24
40
5.7
No
16
24
40
5.0
No
16
32
48
5.3
No
10
16
32
48
4.8
No
11
12
16
16
32
40
48
56
4.4
4.7
No
No
13
16
40
56
4.3
No
14
24
40
64
4.6
No
15
24
48
72
4.8
No
16
24
48
72
4.5
No
1 10 82

Note1: For one TRX, dynamic SDCCHs are over-dimensioned because of the granularity of 8. According to the
Alcatel-Lucent traffic model, all dynamic SDCCHs will not be used.
Note2: An additional dynamic SDCCH/8 must be provided for each DR TRX (these are expected mainly on small
cells).
Rules
At least one static SDCCH/4 or SDCCH/8 on BCCH TRX:
Up to 24 static/dynamic SDCCH sub-channels per TRX.
Up to 32 static/dynamic SDCCH sub-channels per TCU.
Up to 88 static/dynamic SDCCH sub-channels per CELL.

10 Handover Detection for Concentric

Cells
1 10 83


Algorithms
Emergency handovers specific to concentric cells

Intracell handovers from inner to outer zone
cause 10: too low level on the uplink in inner zone
cause 11: too low level on the downlink in inner zone
May be triggered
From inner zone of a concentric cell
Towards outer zone, same cell
Co
n ce
n tr i c c
e
ne
r zon
O ute
1 10 84


r zone
ll
CAUSE 10: too low level on the uplink in the inner zone
and
AV_RXLEV_UL_HO < RXLEV_UL_ZONE

MS_TXPWR = min (P, MS_TXPWR_MAX_INNER)
Averaging window: A_LEV_HO
1 10 85


CAUSE 11: too low level on the downlink in the inner zone
and
AV_RXLEV_DL_HO < RXLEV_DL_ZONE

BS_TXPWR = BS_TXPWR_MAX_INNER
Averaging window: A_LEV_HO
1 10 86


Handover Algorithms Cause 13
CAUSE 13: too high level on UL and DL in the outer zone

Better condition intracell handover
If the cell is a multi-band cell, cause 13 is checked only for multi-band MSs
May be triggered
From outer zone of a concentric cell
Towards inner zone, same cell
n
Co
c e n tr i c c e
ll
ne
r zon
O ute
1 10 87


r zone
Handover Algorithms Cause 13 [cont.]
CAUSE 13: too high level on UL and DL in the outer zone

AV_RXLEV_UL_HO > RXLEV_UL_ZONE +
+ ZONE_HO_HYST_UL +
+ (MS_TXPWR - MS_TXPWR_MAX_INNER) +
and
and
and
and
+ PING_PONG_MARGIN(0,call_ref)
AV_RXLEV_DL_HO > RXLEV_DL_ZONE +
+ ZONE_HO_HYST_DL +
+ (BS_TXPWR - BS_TXPWR_MAX_INNER) +
+ PING_PONG_MARGIN(0,call_ref)
AV_RXLEV_NCELL_BIS(n) <= neighbour_RXLEV(0,n)
EN_CAUSE_13 = ENABLE
(B7)
EN_BETTER_ZONE_HO = ENABLE
Averaging windows: A_LEV_HO and A_PBGT_HO (for n)
1 10 88


ZONE_HO_HYST_UL
UL static hysteresis for interzone HO from outer to inner
In case of multi-band cell, should take into account the difference of
propagation between GSM and DCS
Added to cause 10 threshold RXLEV_UL_ZONE
ZONE_HO_HYST_DL
DL static hysteresis for interzone HO from outer to inner
In case of multi-band cell, should take into account the difference of
propagation between GSM and DCS and the difference of BTS transmission
power in the two bands
Added to cause 11 threshold RXLEV_DL_ZONE
1 10 89



PING_PONG_MARGIN(0,call_ref)
Penalty PING_PONG_HCP put on cause 13 if
The immediately preceding zone in which the call
has been is the inner zone of the serving cell
And the last handover was not external intracell
And T_HCP is still running
PING_PONG_MARGIN(0,call_ref) = 0
If the call was not previously in the serving inner
zone
Or T_HCP has expired
n
Co
c e n tr i c c e
ll
ne
r zon
O ute
1 10 90


r zone
neighbour_RXLEV(0,n)
Inner zone
interferer 1
I n n er z o n e
Inner zone
interferer 2
?
Outer zone
C o n c e n tr i c c e l l
Concentric cells are designed to create an INNER zone

protected from external interferers
and creating no interferences on other cells
to be able to face more aggressive frequency reuse in INNER zone
TRXs
neighbour_RXLEV(0,n) tuning enables to avoid handovers if the MS position
will lead to interferences
the condition is checked towards all neighbor cells belonging to the same
layer and band as the serving cell
1 10 91


EN_CAUSE_13
Load balance between inner and outer zones may be allowed by setting
EN_LOAD_BALANCE = ENABLE
If EN_LOAD_BALANCE = ENABLE
If INNER zone is less loaded than OUTER,
If INNER zone is more loaded than OUTER,
EN_CAUSE_13 = DISABLE
If EN_LOAD_BALANCE = DISABLE
1 10 92


Outgoing Intercell Handovers from Concentric Cell
Outgoing intercell handovers

from concentric cells
As explained here before, the MS
located in a concentric cell can
make intercell, emergency or
better condition HO regardless
their current zone
I n n er z o n e
I n n er z o n e
For example, an MS located

in the INNER zone of a
concentric cell can make
directly an HO cause 12
towards another cell,
WITHOUT having to
trigger any cause 10 or 11
to the OUTER zone before
Outer zone
C o n c e n t r ic c e l l
I n n er z o n e
Outer zone
Outer zone
1 10 93

The only restrictions are linked to EN_MULTI-BAND_PBGT_HO and EN_BI-BAND_MS parameters.

Incoming intercell handovers towards a concentric cell

In case an MS makes an incoming handover towards a concentric cell (due
to outer PBGT measurements,etc.), a TCH may be allocated
either in the INNER or in the OUTER zone, as for call setup
depending on radio conditions
In case of a multi-band cell, if the MS is not multi-band, it will always be
sent to the OUTER zone
I n n er z o n e
Oute r zone
1 10 94
C el l



[cont.]
Use part of Handover cause 13 algorithm on each potential target

IF Cell(n) is external
The MS is directed to the OUTER zone of (n)
ELSE (cell(n) is internal)

IF
AV_RXLEV_NCELL(n) > RXLEV_DL_ZONE + ZONE_HO_HYST_DL +
+ (BS_TXPWR - BS_TXPWR_MAX_INNER)
EN_BETTER_ZONE_HO = ENABLE
and
The MS is directed towards the INNER zone

ELSE
The MS is directed towards the OUTER zone
1 10 95



for this module
1 10 96


End of Module
Annexes
1 10 97


@@SECTION - @@MODULE - 1
@@SECTIONTITLE - @@MODULETITLE
@@PRODUCT
@@COURSENAME
Page blanc
Copyright 2010 by Alcatel-Lucent - All rights reserved

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel

GSM Quality of Service KPIs

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GSM Quality of Service KPIs

Uploaded by

Copyright:

Available Formats

GSM B11

BSS B11 GSM Quality of Service

All Rights Reserved Alcatel-Lucent 2010

All rights reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

Terms of Use and Legal Notices

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

4. Topic/Section is Positioned Here

3. Call Establishment 3JK12193AAAAWBZZA

6. Topic/Section is Positioned Here

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

Course Outline [cont.]

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

Upon completion of this course, you should be able to:

BSS System, in NPO and in a protocol analyzer (K12).

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

Course Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

About this Student Guide

All Rights Reserved Alcatel-Lucent 2010

Where you can get further information

All Rights Reserved Alcatel-Lucent 2010

About this Student Guide [cont.]

Switch to notes view!

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

section you will be asked to fill this questionnaire

Surname, First name :

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

Self-assessment of Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2010

Thank you for your answers to this questionnaire

All Rights Reserved Alcatel-Lucent 2010

Do not delete this graphic elements in here:

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

B11 GSM QoS Monitoring Introduction

This page is left blank intentionally

First edition, B11 MR1

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

B11 GSM QoS Monitoring Introduction

All Rights Reserved Alcatel-Lucent 2010

Module Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2010

B11 GSM QoS Monitoring Introduction

This page is left blank intentionally