3fl10491adaawbzza 02

EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
3FL10491ADAAWBZZA2 Issue 2
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 B10 Introduction to Quality of Alcatel-Lucent 2010 Monitoring All Rights Reserved Service and Traffic Load Page 1
Empty page
Switch to notes view!
2
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 AlcatelLucent. 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 All Rights Reserved Alcatel-Lucent 2010 3 written consent of Alcatel-Lucent.
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 AlcatelLucent 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. AlcatelLucent 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
4
Course Outline
1. This Course AboutGSM QoS Monitoring
4. Topic/Section is Positioned Here
Course outline 1. Introduction 3JK11043AAAAWBZZA Technical support Indicators 3JK11044AAAAWBZZA 2. Global 5. Topic/Section is Positioned Here Course objectives
3. Detailed Indicators 3JK11045AAAAWBZZA
4. Handover Indicators 3JK11046AAAAWBZZA 6. Topic/Section is Positioned Here 1. Topic/Section is Positioned Here

Xxx Xxx Xxx
5. Directed Retry Indicators 3JK11047AAAAWBZZA 6. Radio Measurement Statistics Indicators 3JK11048AAAAWBZZA 7. Topic/Section is Positioned Here 7. Traffic Indicators 3JK11049AAAAWBZZA 8. Case Studies 3JK11050AAAAWBZZA 9. Annexes 3JK11051AAAAWBZ
2. Topic/Section is Positioned Here 3. Topic/Section is Positioned Here
5
Course Outline [cont.]

6
Course Objectives
Welcome to BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Upon completion of this course, you should be able to:
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 optimisation 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
7
Course Objectives [cont.]

8
About this Student Guide

Conventions used in Switch to notes view! this guide
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.
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
Self-assessment of Objectives
Contract number : Course title :
At the end of each section you will be asked to fill this questionnaire Please, return this sheet to the trainer at the end of the training to notes view!
Dates from : Location : to :
Client (Company, Center) : Language : Switch
Number of trainees : 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
Yes (or globally yes) No (or globally no)
Instructional objectives 1 To be able to XXX
Comments
2
11
EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring All Rights Reserved Alcatel-Lucent 2010
Self-assessment of Objectives [cont.]

Instructional objectives Yes (or Globally yes) No (or globally no) Comments
12
Other comments
Thank you for your answers to this questionnaire
11
Do not delete this graphic elements in here:
Section 1 GSM QoS Monitoring

Module 1 Introduction
3JK11043AAAAWBZZA Issue 01
EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring 3FL10491ADAAWBZZA2 Issue 2
All Rights Reserved Alcatel-Lucent 2010 3JK11043AAAAWBZZA Issue 01 Section 1 Module 1 Page 1
Blank Page
112
GSM QoS Monitoring Introduction EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Document History Edition 01 Date 29-June-2010 Author Xavier Pourtauborde Remarks 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 Exercise All Rights Reserved Alcatel-Lucent 2010 1 1 55Indicators Definition GSM QoS Monitoring Introduction EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring 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
1 Monitoring the QoS of the BSS
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
2 Monitoring the Traffic Load of the BSS
1 1 10
2 Monitoring the Traffic Load of the BSS
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
BTS
BSC
Circuit Core Network
BTS BSC BTS
MSC/VLR
GPRS backbone
GGSN
MFS
SGSN
IP Network
1 1 11
3 Information Sources Available
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
OMC-R
NPO
BTS
BSC Circuit Core Network
BTS
MSC/VLR GPRS backbone BSC MFS SGSN
GGSN
BTS
cf. PM file snapshot in the comments
1 1 13
IP Network
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.
Observation Tools [cont.]

NSS Performance: Core Network Counters
OMC-CS
BTS
BSC Circuit Core Network GGSN GPRS backbone MFS SGSN IP Network
BTS
MSC/VLR
BSC BTS
1 1 14
Observation Tools [cont.]

Interfaces Traces: Capture messages through each interface
Post-Processing tool
Drive-tests
Abis trace A trace

BTS BSC Circuit Core Network GGSN GPRS backbone MFS SGSN IP Network
BTS
MSC/VLR
BSC BTS
1 1 15
Interface Trace
Interface
A Interface
Information source
Capture/decode signaling between MSC and BSC-TC (A or Ater MUX) with "protocol analyzer" (Wandel, Tektronix, Gnnettest, etc.)
Advantages
GSM standard, can be used for arbitrage between manufacturers Complete information (message contents, time-stamp) Possible detection of User/MS/BSS/TC/NSS problems
Drawbacks
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) High cost of equipment 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) High cost of equipment Very time-consuming Difficulty to perform a lot of calls -> number of samples insufficient -> only a few streets No uplink
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
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
1 1 16
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: 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 Some typical NSS failure causes are: 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. All Rights Reserved Alcatel-Lucent 2010 3JK11043AAAAWBZZA Issue 01 Section 1 Module 1 Page 16
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
Link to multi-interface & protocol decoding for deep investigation
Visibility / Services
Failing Calls highlighted
Customer complaint analysis
1 1 18
Example of Traces Post-Processing [cont.]

Location Update Failures per IMSI
Abnormal level of Location updates: 2 of biggest cities particularly impacted
Best / Worst performing handsets
View at BSC level Detailed call analysis shows that a group of subscribers owning the same handset keep trying a LU every 2s
+
3 H an 1 H an 5 H an 2 H an 4 H an 5 H an 2 H an 4 H an
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 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 H an ds et 4 1 H an ds et 2 2 H an ds et 4 3 H an ds et 2 4 H an ds et 4 4 H an ds et 3 2 H an ds et 3 2 H an ds et 5 3 H an ds et 3 3 H an ds et 4
ds et 1
ds et 3 ds et 2
ds et 2
ds et 1
ds et 1
ds et 1 ds et 2
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
OMC-R
BSC
OMC-R
NPO
BSC
OMC-R
1 1 22
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

Smallest element for which the counter is provided
Counter Reference
Counter Name
1 1 24
All counters are described in PM Counters document.
BSS Counter Example [cont.]
ts available 15 ts 10 ts 5 ts O 20 40 60 80
1 1 25
All Rights Reserved Alcatel-Lucent 2010 GSM QoS Monitoring Introduction EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
At the end of the hour: 180 samples every 20s Hourly value = SUM of sample /180
t
All counters are described in PM Counters document.
Exercise
Observation Means: find the best source of information.
Observation to be done
1 overall radio quality of 1 cell 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
Best source
Counters
Why
Type 31 : RMS
1 1 26
EM: Electro-Magnetic
4 Introduction to K1205 PC Emulation
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 enter in To enter in monitoring mode to monitoring mode to analyze the analyze the AAtrace trace To filter the main To filter the main GSM protocols and GSM protocols and messages messages To select binary To select binary trace file trace 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
Short View Short View 11line //message line message
To extract 11call To extract call
Frame View Frame View Full decoding of Full decoding of selected message selected message
Packet view Packet view Message content Message content in hexadecimal in 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
MOS : Mean Opinion Score
Typical Thresholds
Not taking into account coverage or frequency planning
% Call Drop % RTCH drop % Call Setup Success (ALU formula) % RTCH Assign Cong % RTCH Assign Fail % SDCCH Drop % SDCCH Assign Cong % Out HO Efficiency
1.50% 1.20% 97.0% 2.0% 1.5% 0.5% 1.0% 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)
Call setup is above 97%

100.%
900 800 700 600 500 nb 400 300 200 100 0

01/07/2009 02/07/2009 03/07/2009 04/07/2009 05/07/2009 06/07/2009 07/07/2009
99.5% Assign Unsucc 99.% % Call drop SDCCH drop 98.5% % End to End Call setup % Call success % Call setup 98.%
97.5%
1 1 40
6 Methodological Precautions
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% 9,95% 2,10%
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
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 10 100 200 400 600 1000 2000 3000 5000 10000 Max 10.7% 4.7% 3.9% 3.4% 3.1% 2.9% 2.6% 2.5% 2.4% 2.3% Min 0.0% 0.0% 0.1% 0.6% 0.9% 1.1% 1.4% 1.5% 1.6% 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:

P +/- 1.96*[(p*(1-p))/n]
Example: for p = 90 % and N = 100 => [ 84,12% ; 95,88% ]
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 Cell B Max congestion Cell C BHc BHb Max traffic = Busy Hour Congestion @ Busy Hour
1 1 45
BSC
max 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
Call drop = 0,9% in your country
Samples (calls)
2456435
Conclusion
All the cells have a good call drop There is a good call setup success rate for cell 15, 145 In France, call setup success= 97% The call drop for BSS_1 is good Cell 15, 13 has certainly a trouble LA = BSS1+BSS2 has a call drop of 2.3% BSS1 belonging to MSC Stadium has a call setup success of 95%
OK / NOK ?
NOK
Call setup success for cell 15, 145 = 99,5%
2315
In Paris: 2500 cells with 95% of call setup success In the rest of France: 5000 cells with 98% Call drop rate for BSS <<BSS_1>> = 1% Call drop for cell 156,13 = 5%
3267872
4500 215
For BSS 1, call drop of 2% For BSS 2, call drop of 3% MSC <<Stadium>> has a call setup success of 95%
4000 2000 15346
1 1 46
Self-assessment on the Objectives

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
12

Module 2 Global Indicators
Blank Page
122
GSM QoS Monitoring Global Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Document History Edition 01 Date 29-June-2010 Author Xavier Pourtauborde Remarks 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
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 Self-assessment on the Objectives End of Module Page 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
125

126
1 Indicators Reference Name
127
1 Indicators Reference Name
Description
Each QOS indicator has a unique REFERENCE NAME of 10 characters.
Family
Unit
mandatory
Technology
Procedure Prefix
Type
Joker Sub-type
optional
128
Tehnology: G (GSM), U (UMTS), W (WiMaX)
2 Indicators Classification
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
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
1 2 11
B11
Limitations 40 cells 40 cells 40 cells 40 cells 40 cells 40 cells Since
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.
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
Handover
Resource availability
Densification techniques
HO causes SDCCH SDCCH Outgoing HO Incoming HO Intracell HO SDCCH/TCH HO Couple of cell Inter-PLMN HO Control Channels
1 2 12
Dynamic SDCCH
Directed retry
TCH
SDCCH availability
Concentric cells
RTCH SCCP
RTCH availability
Multilayer / Multiband Network
Call statistics
3G to 2G HO
A Channel availability
Multiband
Formalism of Telecom Procedures

(start) Telecom procedure -REQUEST no resource available in BSC - congestion
resource available in the BSC channel activation failure - BSS problem - NSS problem
PREPARATION phase
Telecom procedure -whose channel is ALLOCATED in BSC
channel activation success assignment/HO execution failure Telecom procedure -ATTEMPT the MS has seized the channel Telecom procedure -SUCCESS (end) Success Rate = Efficiency Rate Unsuccessful Rate Failure Rate =
1 2 13
EXECUTION phase
- 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
failure in channel established phase
(Success) / (Request) = (Success) / (Allocated) = (Preparation & Execution Failures) / (Request) (Execution Failures) / (Request)
SDCCH Traffic
Traffic Load and Traffic Model SDCCH traffic
Traffic Model Global Requests Normal Assignment Global Traffic Normal Assignment Traffic MT Loc. Update IMSI Detach Sup. Service Call Estab
1 2 14
SDCCH Traffic
MS Penetration Rate Traffic Dual Band Handover
Resource Occupancy SDCCH Erlang SDCCH Mean Holding Time
Handover
Traffic MO LU Follow on SMS Call ReEstab Other

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
Traffic Model
Resource Occupancy TCH Erlang Full Rate Erlang Full Rate Allocated Full Rate Mean TCH Time Blocking Peak TCH Multiband Occupancy Half Rate Erlang Half Rate Allocated Half Rate Mean TCH Time Ratio of HR Traffic
REQUESTS
FR, DR, DR/EFR, AMR, DATA
REQUESTS Assign / HO / DR SUCCESS Assign/ HO/ DR
ALLOCATIONS FR, HR, EFR, AMR, DATA SUCCESS AMR / TFO
HO PER CALL
1 2 15
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).
QoS SDCCH
GLOBAL Quality of Service SDCCH
Assignment Phase / Handover
SDCCH
Established Phase
Congestion Drop Rate Unsuccess Drop Radio Radio Failure Access Reject BSS Failure Drop HO Drop BSS
Dynamic Allocation
1 2 16
QoS RTCH
GLOBAL Quality of service RTCH
Assignment Phase / Handover Congestion
RTCH
Queuing Phase
Preemption Phase
Established Phase
Queue Length
PCI =1 Requests
PVI =1 Success
Drop rate Drop Radio Drop HO
Global Radio Congestion Level Unsuccess
Assign Queuing Fail Queue Full
Assign Queued
Radio Failure
BSS Failure
Assign Queued & Reject Timeout Higher Priority
Queued Success Normal Assign.
Allocation with / without Preemption Success
Drop BSS Preemption
Failure
Directed Retry
1 2 17
QoS Call Statistics

GLOBAL Quality of service Call statistics Call Statistics
Call Success End to End Call Setup Success Rate
Call Drop
Call Setup Success Rate Call Success Rate Drop Radio Cell Quality Factor Absolute Cell Quality Factor Relative
Call Drop Rate
Call Drop End User Rate
Drop HO
Drop BSS
Preemption
Transcoder
Failure
BSS Internal Failure
1 2 18
Handover Causes
Handover STATISTICS Handover causes
Handover causes
HO causes
HO causes per Adjacency
Outgoing HO All HO cause distribution HO standard cause distribution HO cause category distribution
Incoming HO
HO cause category 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
All Rights Reserved Alcatel-Lucent 2010 GSM QoS Monitoring Global Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Incoming Handovers
Handover STATISTICS Incoming handovers
Intra-BSC
Incoming HO
External
Intra-BSC & External
Efficiency
Efficiency
Efficiency
Congestion
Congestion
Failure Radio
Failure No CIC
Failure BSS
Failure Radio
Incoming external HO 3G - > 2G Incoming external HO 2G - > 2G only

1 2 21
All Rights Reserved Alcatel-Lucent 2010 GSM QoS Monitoring Global Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Failure BSS
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)
CDR Radio
Call Drop Rate 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

1 2 24
End of Module Global Indicators
1 2 25
13

Module 3 Detailed Indicators
Blank Page
132
GSM QoS Monitoring Detailed Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Document History Edition 01 Date 28-june-10 Author Xavier Pourtauborde Remarks 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 Procedure 2/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 Congestion RLE - SDCCH Cong. Impacts RLE - SDCCH Cong. Causes & Solutions RLE Dynamic SDCCH RLE - SDCCH Radio Failure RLE - Real SDCCH Radio Failures RLE - Ghost RACH All Rights Reserved Alcatel-Lucent 2010 135 GSM QoS Monitoring - Ghost RACH Causes RLE Detailed Indicators Introduction to Quality of Service and Traffic Load Monitoring EVOLIUM Base Station Subsystem BSS B10 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

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 Self-assessment on the Objectives End of Module Page 66 68 70 72 73 74 75 76 78 79 81 82 83 84
136
1 Call Setup Principles
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
Call Setup Procedure 1/2

MS BSS MSC/VLR HLR/AuC/SCP/
CCCH
Channel Request (RACH) Immediate Assignment (AGCH) Establish Indication "CM Service Request" Connect Req. (CR) Connect Conf. (CC) MM Authentication Procedure MM Identity Request MM/RR Ciphering Procedure MM/RR TMSI Reallocation Procedure CC Setup CC Call Proceeding Translation of the Called Number Assignment Command Assignment Complete Assignment Request (CIC) Subscription Checking (calling party rights, call barring) Security Checks
Call
Setup
Phase
TCH
SDCCH
Release of SDCCH Radio Channel
Assignment Complete
139
Call Setup Procedure 2/2

MS BSS MSC/VLR HLR/AuC/SCP/ MAP Send Routing Info. V-MSC/VLR
Call Setup Phase

CC Alerting
MAP Send Routing Info. Res ISUP IAM ISUP ACM
If Called Nb = MSISDN
Called party free & ringing Called party Answered
TCH
ISUP ANC CC Connect CC Connect Ack.
Conv. Phase Call Rel. Phase

CC Disconnect
Conversation phase
CC Release CC Release Complete Release of Radio Resources
ISUP CLF
ISUP RLG
1 3 10
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

4 steps for a call establishment
Radio Link Establishment SDCCH Phase TCH assignment Alerting/CNX Phase
Each phase has a specific utility and some weaknesses In the table, indicate which phases are used for each type of connection:
1 1 2 2 3 3
CALL SETUP PHASES Signalling (LU, Signalling CALL SETUP PHASES IMSI Det) Radio Link Establisment Radio Link Establisment SDCCH Phase SDCCH Phase TCH Assignment TCH Assignment
SMS SMS
Call Call (OC/TC) GPRS Transfer GPRS Transfer
4 Alerting/Connection
1 3 11
Paging
MS is "IMSI-attached" to the network: the MSC/VLR knows the L.A. in which the MS is located.
BSC 1
MSC
LAC 001 ISUP IAM
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 MC940 MC940 MC940 MC925g x 3 MC930 x 1
Paging Request for Group 1 (MS1 , MS2) Paging Request for Group 3 Multiple Paging Command CS Paging (MS1) CS Paging (MS2) CS Paging (MS3)
MC8a
(MS1 pgr1, MS2 pgr1, MS3 pgr2)
MC925b MC925b
T3113
Connection Setup
(MS3)
Establishment Indication incl. Paging Response

1 3 13
timer stopped
MC01
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 MC940 MC940 MC940 MSC
CS Paging (MS1) CS Paging (MS2) CS Paging (MS3)
Paging Queue is full Paging Command is rejected
MSC timer Multiple Paging Command
MC8a
T3113
(MS1 pgr1, MS2 pgr1, MS3 pgr2)
MC925h x 1
CS Paging (MS3)
timer expires
1 3 14
In case of RSL DL Congestion (= LAPD Congestion), the Pagings are not sent on the Abis interface anymore. IF MSC timer T3113 expires, the MSC will retransmit the paging over the whole LAC or even more (whole BSC, whole network, )
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 Type 1 Max. paged MS 2 IMSI or TMSI or 2 x TMSI or 2 x IMSI or 1 TMSI + 1 IMSI Type 2 3 Type 3 4
Possible combinations
3 x TMSI 4x TMSI or 2 x TMSI + 1 IMSI
most common
1 3 15
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.
2 Typical Call Setup Failures
1 3 16
RLE Originated Call Success

MC925d MC925e MC925a
MC8c MC148 IP21 MC8b

only in case of IP BSS
MC02
C253 C256
CR and CC messages are contains the SCCP references to be used for the call
1 3 17
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 : SCCP 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). C253 and C256 are type 25 counters (related to SCCP measurements).
RLE Terminated Call Success

MC8a
MC925d MC925e MC925a

only in case of IP BSS
MC01
C253
C256
1 3 18
All Rights Reserved Alcatel-Lucent 2010 GSM QoS Monitoring Detailed Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
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 7 6 5 4 3 2 1 Establishment Cause Establishment Cause Establishment Cause Establishment Cause Random Reference Random Reference Random Reference Random Reference
Valid causes :
000 100 101 110 111 011 : Location update (Normal, periodic, IMSI attach) : Terminating Call : Emergency Call : Call Re-establishment : Originating call (Not Emergency) : If GPRS is implemented in the cell
Invalid causes : 001, 010, 011
1 3 19
NECI: New Establishment Cause Indication (0: not supported, 1: supported), is always set to 1 in AlcatelLucent BSS
RLE Call Distribution

Mobile Originating Cause Split: MC02 = MC02a+MC02b+MC02c+MC02d+MC02e+MC02f+MC02g+MC02h+MC02i
MC02A: Location Update & IMSI Attach MC02B: SMS MC02C: Supplementay Services MC02D: Location Update with follow-on TCH assignment for call establishment MC02E: Call Reestablishment MC02F: L3 Info unknown by BSC but forwarded to MSC MC02G: IMSI Detach MC02H: Normal or Emergency call MC02i: Location Services (LCS)
1 3 20
Could you find any other counters that would give more details about SMS? C190 (Type 19) SMS Originated SDCCH C191 (Type 19) SMS Terminated SDCCH In NPO, in indicator family "SMS"
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 identication 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 21
LAPD Congestion will lead to 1/ Defense mechanism : if UL RSL Congestion: Channel Requests, SMS and Detection of Call drop due to Remote Transcoder are discarded if DL RSL Congestion: Paging, "SDCCH" Channel activation and SMS are discarded 2/ If congestion continues and the Lapd buffers overflow, then the LapD link is RESET. Congestion and Reset are counted in the LapD counters.
RLE - SDCCH Congestion

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
(130ms)
1
MC04 Time during which the SDCCH are all busy in the cell: SDCCH_time_system_con gestion = MC803 MC803
MC8c
T3120
2
MC04
MC8c
T3126
MS goes back to IDLE MODE & displays "Network Error"
MC04
1 3 22
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 S+T-1 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 3GPP 331121 from 44.018: TX_integer 3, 8, 14, 50 4, 9, 16 5, 10, 20 6, 11, 25 7, 12, 32 S(CCCH Not Comb) 55 76 109 163 217 S(CCCH Combined) 41 52 58 86 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.
RLE - SDCCH Congestion

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
(=5s)
1
(AGCH)
IMMEDIATE ASSIGMENT REJECT(WI_OC)
MC8d
MC04 Time during which the SDCCH are all busy in the cell: SDCCH_time_system_con gestion = MC803 MC803
MC8c
WI_OC
2
(AGCH)
MC8d MC04
MC8c
T3126
(AGCH)
MC8d
MC04
MS goes back to IDLE MODE & displays "Network Error"
1 3 23
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 1 2 3
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 24
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 (T11) is taking too long (while MS in queue, the SDCCH remains allocated) Increase RACH_TA_FILTER with care!
1 3 25
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 a particular 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)
st que l Re ne han
se Noi EM
The Ghosts !
Real Subscribers
1 3 26
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 MC801b Max TCH busy on a SDD
MC802a Avg SDCCH subchannels busy on a SDD MC802b Max SDCCH subchannels busy on a SDD
1 3 27
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
MC925d
T3101 expiry !! (def. 3s) No Establishment Indication

1 3 28
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 29
Unbalanced Power Budget:
AGCH RACH
Max Path Loss DL Max Path Loss UL
Channel Request
Bad coverage:
building
BTS
Access Grant
RACH
Interference:
AGCH lost
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 30
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 31
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 REQUIRED (1) RTT Ch. Act.

Ch. Act. Ack.
CHANNEL REQUEST (2)
IMM. ASSIGNMENT (1)
. (1) IMM. ASSG . (2) IMM. ASSG
In this scenario: MC8c =2 MC8b =2 MC148 =2 MC02 =1 MC149 =1

1 3 32
Compute the value of SDCCH_assign_fail_radio_rate = 1 / 2 = 50%
The CHANNEL REQUEST (2) is followed of the MULTIFRAME in "TIME SLOT" 0 Ack but they are not STRUCTURE by Channel Required, Ch. Act, Ch Act represented 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
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
(Multiframes of 51 frames)
C C C C = CCCH (PCH or AGCH)
DOWNLINK f = FCCH s = SCH b = BCCH R = RACH
(Combined BCCH)
DOWNLINK FS FS B B C C FS FS C C C C FS FS D0 D0 D1 D1 FS FS D2 D2 D3 D3 FS FS A0 A2 A1 A3 -
UPLINK D3 D3 RR RR A2 A0 A3 A1 RRRRRRRRRRRRRRRRRRRRRRR RR RR RR RRRR R R RR R RR RR R RR R C = CCCH (PCH or AGCH) D0 D0 D1 D1 RR RR D2 D2 Dn/An = SDCCH/SACCH/4
F = FCCH S = SCH B = BCCH
R = RACH
51 multiframe duration = 51 x 8 x 0,577 = 235ms

RLE Co-BCCH/BSIC
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 nearby"
Encrypted using the BSIC of the serving cell (3GPP TS45.003)
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 33
cell 019 BCCH = 20 BSIC = 4-1
Different BSIC will prevent this problem to happen. BSIC = BCC (3 bit) + NCC (3 bit)
q q
BCC: BTS Color Code NCC: Network Color Code
TB : Tail Burst (0,0,0) GP : Guard Period
RLE Co-TCH/BSIC
Same idea with worse impact MS doesn't send one HO Access but four!
Encrypted using the 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 ! cell 019 TRX1 = 24 TRX2 = 28 TRX3 = 30 BSIC = 4-1
success ! cell 001 TRX1 = 14 TRX2 = 24 TRX3 = 26 BSIC = 4-1

1 3 34
BSIC = BCC (3 bit) + NCC (3 bit)

q q
BCC: BTS Color Code NCC: Network Color Code
RLE HO ACCCESS vs BCCH [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 35
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 36
RLE - Summary
REQUEST
GSM valid causes ATTEMPT Preparation Failure Congestion
invalid causes
Radio Link Establishment
Request MC8C unknown unknown MC04 unknown MC148 MC149 MC148 - (MC01+MC02) - MC149 MC01+MC02
Preparation
GSM invalid causes GSM valid causes Congestion BSS Pb
BSS problem
SUCCESS
Execution Failure Radio access failure BSS problem
Execution
Attempt Radio Access Failure BSS Pb Success
1 3 37
RLE - Indicators
In this graph, important informations are missing, which ones? Congestion ! And the Unsuccess %
1 3 38
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
Cong (BH, Max) SDCCH_Load Unavailability Traffic Model
REQUEST
Preparation Phase SDCCH_assign _unsuccess_rate SDCCH_assign _cong_rate
ATTEMPT
Execution Phase
SDCCH_assign _fail_rate
Radio Fail BSS Fail
SUCCESS
Fill up the table with indicators to monitor each phase
1 3 39
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 AUTHENTICATION RESPONSE CIPHER MODE Command CIPHER MODE Complete IDENTITY REQUEST IDENTITY RESPONSE TMSI REALLOC Command TMSI REALLOC Complete CALL SETUP CALL PROCEEDING
IMSI check A5/x = ON IMEI check TMSI changed other side = OK

Paging of called party
AP DT es ag ss e
1 3 40
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
SDCCH Phase Terminated Call Success

Only the 2 last messages are changed
AUTHENTICATION REQUEST AUTHENTICATION RESPONSE CIPHER MODE Command CIPHER MODE Complete IDENTITY REQUEST IDENTITY RESPONSE TMSI REALLOC Command TMSI REALLOC Complete CALL SETUP CALL CONFIRM
IMSI check A5/x = ON IMEI check TMSI changed other side = OK

CALL PROCEEDING to calling party
AP DT s ge sa es
1 3 41
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
SDCCH Phase Location Update Success

Goal: Update VLR with new LAC, and reallocate TMSI in MS
CLASSMARK ENQUIRY CLASSMARK CHANGE
CLASSMARK ENQUIRY CLASSMARK CHANGE AUTHENTICATION REQUEST AUTHENTICATION RESPONSE CIPHER MODE Command CIPHER MODE Complete IDENTITY REQUEST IDENTITY RESPONSE LOCATION UPDATE Accept TMSI REALLOC Complete CLASSMARK Update
Optional (BSS_SEND_CM_ENQUIRY) Retrieve MS capabilities
IMSI check A5/x = ON IMEI check

AP DT es ag s es
TMSI changed
1 3 42
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 43
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

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 44
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

MS BTS BSC SDCCH Phase established MSC
MC137 MC137
C180b --------------------------------------- > or d CLEAR REQUEST

Cause : O&M intervention Cause : radio interface failure
1 3 45
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

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

1 3 46
Drop !
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
Drop radio Drop BSS
What are the cases of "normal release"? End of the Location Update, IMSI Detach, SMS, SS procedures.
Drop HO
SDCCH Phase
SDCCH connection MC01+MC02+MC10 Drop radio Drop BSS Drop HO MC138 MC137 MC07
SDCCH Drop
1 3 47
SDCCH Phase - Indicators
1 3 48
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 49
TCH Assignment Success Case
B11
MC140a
PHYSICAL CONTEXT REQ. PHYSICAL CONTEXT CNF. CHANNEL ACTIVATION CHANNEL ACTIVATION ACK.
ASSIGNMENT REQUEST
Trr1
T9108 stop MC703 T9103 stop MC140b T3107
SDCCH
ASSIGNMENT COMMAND
ATER CONNECT REQUEST ATER CONNECT ACK.
TCH
SABM (FACCH) UA (FACCH) ASSIGNMENT COMPLETE (FACCH)
ESTABLISH INDICATION
RMS31 (*) stop MC718 stop
1 3 50
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
CHANNEL ACTIVATION
ASSIGNMENT REQUEST
RTCH_assign_request = REQUEST Preparation Phase RTCH_assign_command = ATTEMPT Execution Phase
MC703
ASSIGNMENT COMMAND
MC140b
ASSIGNMENT COMPLETE (FACCH)
MC718
RTCH_assign_success = SUCCESS
Which indicator is linked to MC703?

RTCH_Assign_Allocated
1 3 51
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
TCH Assignment MS Capabilities

MS supports only FR MS supports only FR & DR Most MS MS supports EFR, FR & DR MS supports AMR FR & AMR HR Data calls MS supports only EFR & FR MS supports only EFR and/or HR MS supports AMR WB GMSK Next-gen MS MS supports A5/3 ciphering MC951
B11
B11
MC701a MC701b MC701c MC701d MC701e MC701f MC701g MC932

NPO ASSIGNMENT REQUEST
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 52
Next-Gen: Next Generation
TCH Assignment - Congestion
B11
MC140b
no TCH available in the cell
ASSIGNMENT REQUEST
MC612a/b/c/d
ASSIGNMENT FAILURE "No Radio Resource Available"
4 causes of congestion 4 counters. If no TCH available and

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
MC612 a.
RTCH_assign_cong = MC812 = MC612x

1 3 53
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: Check importance of problem thanks to: RTCH_assign_cong_rate_BH & RTCH_assign_cong_rate_BH & Hourly RTCH_assign_cong_rate hourly RTCH_assign_cong_rate
If real problem (not temporary peak), then 2 main possible problems
hardware problem? hardwareproblem? tch availability TCH availability OMC-R Alarms OMC-R Alarms tch traffic BH per TRX TCH traffic BH per TRX tch duration avg per TRX TCH duration avg per TRX Solutions: Exchange TRX Activate HR Share load with other cells Solutions: Exchange TRX Activate HR Share load with other cells
too much traffic? tch traffic BH per cell TRX TCH traffic BH per rtch TCH traffic BH per cell traffic load RTCH traffic load Ratio of HR Ratio of HR Ratio of AMR HR Ratio of AMR HR tch queing indicators TCH Queuing indicators Solutions: Add TRX Solutions: Activate HR Share load with other cells Add TRX
Activate HR Share load with other cells
too much traffic?
1 3 54
TCH Assignment - Radio Failure in TCH Uplink
MC140a
PHYSICAL CONTEXT REQ.
ASSIGNMENT REQUEST
Trr1
SDCCH
PHYSICAL CONTEXT CNF. CHANNEL ACTIVATION CHANNEL ACTIVATION ACK. SDCCH in DL still probably OK ASSIGNMENT COMMAND
MC703
MC140b
T3107
SABM (FACCH)
TCH
x x
retransmitted up to N200_LE times SABM UA ASSIGNMENT FAILURE ESTABLISH INDICATION
SDCCH
stop MC746b
ASSIGNMENT FAILURE Radio interface failure w/ rev ASSIGNMENT REQUEST
expiry
1 3 55
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
MC703
MC140b
T3107
SABM (FACCH)
ESTABLISH INDICATION x x UA UA ESTABLISH INDICATION UA
TCH
SABM (FACCH) x N200_LE SABM
RMS31 (*)
SDCCH
stop MC746b
ASSIGNMENT FAILURE Radio interface failure w/ rev ASSIGNMENT REQUEST
ASSIGNMENT FAILURE
expiry
1 3 56
TCH Assignment - Radio Failure at T3107 expiry
MC140a
ASSIGNMENT REQUEST
Trr1
SDCCH
MC703
MC140b
T3107 (14s)
SABM (FACCH)
TCH
x x
SABM (FACCH) x N200_LE SABM SABM x N200_LE
SDCCH
x x
expiry MC746b
ASSIGNMENT FAILURE Radio interface failure ASSIGNMENT REQUEST
expiry
1 3 57
SABM: Set Asynchronous Balanced Mode
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 58
"Probable cause" is just a possibility: It is not the only possible cause !
TCH Assignment - Counters

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

TCH Assignment - Indicators
1 3 60
Report: Alc_Mono_Call
TCH Assignment - Exercise

TCH assignment failure and BSC With K1205 (file PAIB29.REC)
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).
1 3 61
3 Key Performance Indicators
1 3 62
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 63
SDCCH Congestion Rate

Reference name GSDNACGR
Indicator
SDCCH ASSIGN CONG RATE
Formulae
(MC04) / SDCCH ASSIGN REQUESTS
Threshold 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 )
Unit %
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 64
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
Number
(G) means that the indicator is GSM
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)
5000 4500 4000 3500 3000 nb 2500 2000 1500 1000 500 0 00 00:00 01 01:00 02 02:00 03 03:00 04 04:00 05 05:00 06 06:00 07 07:00 08 08:00 09 09:00 10 10:00 11 11:00 12 12:00 13 13:00 14 14:00 15 15:00 16 16:00 17 17:00 18 18:00 19 19:00 20 20:00 21 21:00 22 22:00 23 23:00 0.00% 0.01% 0.01% 0.02% % Congestion Request % Congestion 0.02% 0.03%
1 3 65
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: GLOBAL Quality of service INDICATORS > SDCCH > Assignment phase GSDNACGR: SDCCH assignment failure rate due to congestion (Global)
SDCCH Failure Rate

Reference name GSDNAFLR
Indicator
SDCCH ASSIGN FAIL RATE
Formulae
MC149 + SDCCH_assign_fail_BSS / SDCCH ASSIGN REQUESTS
Threshold 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 )
Unit %
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 happen because of hard- or software failures
1 3 66
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
Number
(G) means that the indicator is GSM
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 4500 4000 3500 3000 nb 2500 2000 1500 1000 500 0 00 00:00 01 01:00 02 02:00 03 03:00 04 04:00 05 05:00 06 06:00 07 07:00 08 08:00 09 09:00 10 10:00 11 11:00 12 12:00 13 13:00 14 14:00 15 15:00 16 16:00 17 17:00 18 18:00 19 19:00 20 20:00 21 21:00 22 22:00 23 23:00 .0% 4.0% 2.0% 6.0% % 10.0% 8.0% 12.0%
Fail - BSS Fail - Radio Success % Fail
1 3 67
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: GLOBAL Quality of service INDICATORS > SDCCH > Assignment phase
SDCCH Drop Rate

Reference name GQSSDCDR
Indicator SDCCH_drop_rate
Formulae (MC138 + MC07 + MC137) / SDCCH ASSIGN SUCCESS
Threshold 4%
Comments Drop radio + Drop HO + Drop BSS
Unit %
SDCCH DROP RATE

Rate of dropped SDCCH (SDCCH is established for any transaction OC, TC, LU,etc.)
1 3 68
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 50 40 1.5% nb 30 1.% 20 10 0 00 00:00 01 01:00 02 02:00 03 03:00 04 04:00 05 05:00 06 06:00 07 07:00 08 08:00 09 09:00 10 10:00 11 11:00 12 12:00 13 13:00 14 14:00 15 15:00 16 16:00 17 17:00 18 18:00 19 19:00 20 20:00 21 21:00 22 22:00 23 23:00 0.5% % 2.5%
2.% Drop - BSS Drop - HO Drop - Radio % Drop
0.%
1 3 69
RTCH Assign Unsuccess Rate

Indicator RTCH_assign unsuccess_rate Formulae (RTCH ASSIGN REQUESTS RTCH ASSIGN SUCCESS) / RTCH ASSIGN REQUESTS Threshold 3% Comments Reference name GTCNAUR Unit %
RTCH 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 70
In a dense network, the TCH assignment unsuccess rate should be lower than 1%.
IN D IC A T O R D E F IN IT IO N FORM U LA B8 TH R ESH O LD COM M ENT M C 1 4 0 a : n e w c o u n t e r i n t r o d u c e d in B 8 r e l e 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 r e q u e s t s f o r T C H e s t a b li s h m e n t ( i n H R o r F R u s a g e ) TCNARQN U N IT N um ber T C H A S S IG N R E Q U E S T S N u m b e r o f T C H s e iz u r e r e q u e s t s f o r n o r m a l a s s i g n m e n t p r o c e d u r e .
c e ll
M C 140a
REF NAM E
INDICATOR DEFINITION FORMULA B8 THRESHOLD COMMENT REF NAME
TCH ASSIGN SUCCESS Number of TCH successfully seized by MS for normal assignment procedure. TRX (MC718)
TCNASUN
UNIT
Number
RTCH Assign Unsuccess Rate Preparation Phase

RTCH Assign Preparation
RTCH assign preparation - CELL2G: 02/03/2009 00 00:00 To 02/03/2009 23 23:00 (Working Zone: Global - Medium)
1400 1200 1000 800 nb 600 400 200 0 7.00% 6.00% 5.00% 4.00% % 3.00% 2.00% 1.00% 0.00% Prep Fail BSS Congestion Request % Prep Fail BSS % Congestion
00 :0 0
02 :0 0
04 :0 0
06 :0 0
16 :0 0
20 :0 0
08 :0 0
10 :0 0
02
04
06
10
12
08
00
14
16
14 :0 0
20
18 :0 0
12 :0 0
1 3 71
18
22
22 :0 0
RTCH Assign Unsuccess Rate Execution Phase

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

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

RTCH_HO_Cong_Rate RTCH_HO_cong / RTCH_HO_request 3% Incoming HO (TCH intra & intercell) RTCH_cong_rate (RTCH_assign_cong + RTCH_HO_cong) / (RTCH_assign_request + RTCH_HO_request) (RTCH_assign_cong + HO_Inc_cong) / (RTCH_assign_request + RTCH_HO_allocated + HO_Inc_cong) 3% NA + Inc HO (TCH intra & intercell) 3% Inc HO takes into account SDCCH & TCH intercell HO GQSCGR GTCAHCGR GTCHOCGR
Call_cong_rate
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 73
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
ESTAB IND (CM_Serv_Req)
MSC
SDCCH assignment success SCCP CON REQ (CM_Serv_Req) SCCP CON CONFIRM
Authentification Procedure Identification Procedure Ciphering Procedure SDCCH Drop incl. Call, SMS, LU IMSI Detach, etc
SETUP CALL PROCEEDING ASSIGNMENT REQUEST

Assignment Procedure TCH Assign Unsuccess (for normal assignment only)
ASSIGNMENT COMPLETE ALERTING CONNECT
Normal assignment success
CONNECT ACK.
1 3 74
GQSEECSSR
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.
Call Setup Success Rate [cont.]

Indicator Formulae Threshol d Comments Reference name Unit
Call_setup_success _rate
(1 SDCCH DROP RATE) * (1 - TCH ASSIGN UNSUCCESS RATE)
95%
SDCCH assignment unsuccesses are not considered in CSSR as : ghost (spurious) RACH cannot be discriminated from a real access failure effect of re-attempts performed autonomously by the MS cannot be quantified
GQSCSSR
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 75
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 AlcatelLucent 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

Thresho ld Reference name
Indicator
Formulae
Comments
Unit
Call_success_rate
(CALL SETUP SUCCESS RATE) * (1 CALL DROP RATE)
92%
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 76
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
SETUP CALL PROCEEDING ASSIGNMENT REQUEST

Assignment Procedure
E2E CSSR
ASSIGNMENT COMPLETE ALERTING CONNECT Normal assignment success
CONNECT ACK.
1 3 77
GQSEECSSR
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.
End to End Call Setup Success Rate [cont.]
Indicator
Formulae
Threshold
Reference Unit name
End_to_End_call_setup (RTCH_assign_success + DR_Out_internal_success + DR_Out_external_success) _success_rate

/ (MT_SDCCH_assign_success - SDCCH_SMS_MT_PP_connection+ SDCCH_traffic_Call_reestab + SDCCH_traffic_lu_for + SDCCH_traffic_other_mo + SDCCH_traffic_moc)
91%
GQSEECSSR
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 78
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 79
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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 E2E CSSR X X Degraded
2.
SDCCH Drops mostly during Location Updates & SMS & IMSI Detach
Not impacted Legacy CSSR E2E CSSR X Degraded X
1 3 80

1 3 81
End of Module Detailed Indicators
1 3 82
14

Module 4 Handover Indicators
Blank Page
142
GSM QoS Monitoring Handover Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Document History Edition 01 Date YYYY-MM-DD Author Last name, first name Remarks 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
143
144
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 Outgoing Internal HO - Indicators All Rights Reserved Alcatel-Lucent 2010 1 4 5 Intra-Cell HO / Internal HO - Exercise GSM QoS Monitoring Handover Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring 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 7 Key Performance Indicators Handover Cause Distribution Handover Standard Cause Distribution Handover 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

Handover Failure Main Causes Page 63
146
1 Handovers Overview
147
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
1 2
Radiolink Measurements Active Channel Preprocessing HO Detection Candidate Cell Evaluation HO Preparation HO Execution
CELL (S)
3
CELL (T)
4
channel activation handover command
5 6
148
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) Point of view from the target cell
Internal
External
Serving and Target cells belong to different BSCs (inter-BSC) Point of view from the serving cell
Incoming
Outgoing
Seving and Target cells are synchronized
Synchronous
Async.
Serving and Target cells 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
149
2 Intra-Cell Handovers
1 4 10
Intracell HO - Success
MS Cell BSC (detection of intracell HO) MC870 Physical Context Request Physical Context Confirm Channel Activation (new ch) Channel Act. Ack (new ch) Assignment Command MC871 T9103 *TC* MSC
T9108
Assign Command SABM (new ch) UA (new ch) Assign Complete (new ch)
T3107
Establish Indication (new ch)
Assign Complete
MC662 Handover Performed BSC Shared DTM Info Indication only for DTM-capable MS
RF Channel Release RF Channel Release Ack

1 4 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
(*) No specific counter
HO_Cell_ROC HO_Cell_drop_radio HO_Cell_drop_BSS *
1 4 12
Failure - Congestion
MS Measurement Report Cell Measurement Result (detection of intracell HO) MC870 (no free channel) MC561 TCH MC101 / SDCCH BSC
MC561: 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.
1 4 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) X UA (new) SABM (new) 200ms X UA (new) SABM (new) X UA (new) etc etc etc Assign Failure (old) Assign Failure
Physical Context Request (new) Physical Context Confirm (new) RF Channel Release (new) RF Channel Release Ack (new)
1 4 14
All Rights Reserved Alcatel-Lucent 2010 GSM QoS Monitoring Handover Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Cell Assignment Command Establish Indication
BSC
MC871
T3107
T200_TF try N200_TTF times 200ms
MC667
stop
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
Cell
BSC
Assign Command (old)
Assignment Command
MC871
T3107
Channel release of old and new channels
MC663
1 4 15
MC663 = C103 (sdcch) + C63 (tch)
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 4 16
Intra cell HO failures due to BSS problems are deduced from other counters.
Main Counters
HO FAIL. CASES > intracell HO counters
REQUEST
ATTEMPT
Preparation Failure
SUCCESS
INTRACELL Handover Preparation
Request Congestion BSS Pb MC870
Execution Failure
CONGESTION BSS PB
MC561+MC101 MC870-MC871-(MC561+MC101) MC871
REVERSION OLD CHANNEL
Execution
Attempt
Reversion old channel MC667 Drop radio MC663 BSS Pb MC871-MC662-MC667-MC663 Success
1 4 17
DROP RADIO DROP BSS
MC662
3 Internal Intercell Handovers
1 4 18
Internal HO Success (Async)

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

HO Command HO Access * 4 HO Detection SABM (new ch) UA (new ch) Assign Complete (new ch) Handover Complete MC656 MC652 Establish Indication MC660 MC871 T3103
TCH
speech
Handover Performed BSC Shared DTM Info Indication only for DTM-capable MS MFS
(old channel release)

1 4 19
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
Serving Cell
1 4 20
Incoming Internal HO - Failures

Causes of Failures :
Handover procedure from the target cell point of view Handover Preparation:
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 4 21
Incoming Internal HO - Congestion
MS
Serving Cell
Serving BSC
MSC
MEAS REPORT ----------------------------->
MEASUREMENT RESULT --------------------------------------------------------------> MC830 No free TCH MC551
1 4 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 -----------------------> ESTABLISH INDICATION 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 4 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
Preparation Failure
SUCCESS
INCOMING INTERNAL Handover Preparation Request Congestion BSS Pb Execution Attempt Radio (MS access problem) BSS Pb Success
1 4 24
Execution Failure
CONGESTION
MC830 MC551+MC91 MC830-MC831-(MC551+MC91)
BSS PB
MS ACCESS PB
MC831 MC653 MC831-MC652-MC653 MC652
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 4 25
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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 Handover Preparation:
Preparation Failures (no details)
Handover Execution:
radio problem: the MS reverts to the old channel radio problem: the MS drops BSS problem (no specific counter)
1 4 26
Outgoing Internal HO - Radio Failure ROC

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 SABM -----------------------> ESTABLISH INDICATION UA ------------------------------------------------------------------------> <----------------------HO FAILURE HANDOVER FAILURE -----------------------> ------------------------------------------------------------------------> MC657 Release of new channel
1 4 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 T3103 expiry MC658 Clear_request ------------------------> Clear_command Release of old and new TCH <------------------------
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 4 28
Outgoing Internal HO - Counters

HO FAIL. CASES > Outgoing internal HO counters
REQUEST
ATTEMPT
Preparation Failure
SUCCESS
OUTGOING INTERNAL Handover
Execution Failure
CONGESTION
BSS PB
Preparation Request Any preparation failure Execution Attempt Reversion old channel Drop radio BSS Pb Success
1 4 29
MC655A MC655A-MC660 MC660 MC657 MC658 MC660-MC656-MC657-MC658 MC656

REVERSION OLD CHANNEL DROP RADIO BSS PB
Outgoing Internal HO - Indicators
HO_Out_BSC_request
HO_Out_BSC_required
HO_Out_BSC_prep_fail
HO_Out_BSC_success
HO_Out_BSC_ROC
HO_Out_BSC_drop_radio
HO_Out_BSC_drop_BSS
1 4 30
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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
1 4 31
4 External Intercell Handovers
1 4 32
External HO - Success
MS
serving_cell
BSC
MSC
BSC
target_cell
MS
- MEAS_REPORT -> ------- MEAS_RESULT --------> MC645A ------ HO_REQUIRED ----------> MC462A Start T7 ----------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 --> <--- SABM ------------------- UA -------------->
Stop T7 <------------------------- HO_COMMAND -----------------------------------------------------MC650 Start T8 MC462B
<---- HO_ACCESS ----<---- HO_ACCESS -----
<----- ESTABLISH_INDICATION ----
<--- HO_COMPLETE --------------MC462C Release of TCH <---- CLEAR_COMMAND -----MC646 Cause HO_SUCCESSFUL : Stop T8
<----------- HO_COMPLETE ---------------------------------------Stop T9113 MC642 MC463C
1 4 33
T7 and T8 are timers used to monitor the handover management. T7 : timer between HOREQ and HOCMD, T8 : timer between HOCMD and HOCMP. 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. All Rights Reserved Alcatel-Lucent 2010
3JK11046AAAAWBZZA Issue 01 Section 1 Module 4 Page 33
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_no_cic_alloc
HO_Inc_MSC_prep_fail
(deduced)
HO_Inc_MSC_success
HO_Inc_MSC_fail_radio
HO_Inc_MSC_fail_BSS
(deduced)
1 4 34
"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
target_cell
MS
- MEAS_REPORT -> ------- MEAS_RESULT --------> MC645A ------ HO_REQUIRED -------> ----------CR (HO_REQUEST) -----> < ----- HO_FAILUR --------------E Cause: no radio resource available MC820 MC541A
( < -HO_REQUIRED_REJECT-)
1 4 35
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)
Incoming External HO TTCH (CIC) Congestion
MS
serving_cell
BSC
MSC
BSC
target_cell
MS
- MEAS_R EPORT -> ------- MEAS_RESULT --------> M C645A ------ HO_REQUIRED -------> ----------CR (HO_REQUEST) -----> < ----- HO_FAILURE --------------Cause: terrestrial circuit already allocated Requested terrestrial resource unaivalable BSS not equiopoed ( < -HO_REQUIR ED_REJECT-) MC820 MC41B
1 4 36
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_R EPORT -> ------- MEAS_RESULT --------> EQUIRED -------> MC645A ---- HO_R ----------CR (HO_R EQUEST) -------------------> < -------- CC --------------------------------------< ----- HO _REQUEST_ACK----------------------(HO-CO MMAND) included < -------------------------- HO_COMMAND -----------------------------------------------Sta rt T8 ----- SABM --------> < --- UA ------------MC820 - CHANNEL_ACT ----------> < --- CHA_ACT_ACK -------Sta rt T9113 MC821 X --- HO_ACCESS ----X ---- HO_ACCESS -----
-- ESTABLISH_INDICATION->
MS----- HO_FAILURE (reversion to old channel) serving_cell

- MEAS_REPORT ->
BSC ------------------------------------------>
MSC
----- CLEAR _COMMAND ----------------------> Radio interface fail : R eversion to old channel
BSC
MC643 Release of connection
target_cell
MS
------- MEAS_RESULT --------> MC645A ---- HO_REQUIRED ------->
----------CR (HO_REQUEST) -------------------> < -------- CC ---------------------------------------
< ----- HO_REQUEST_ACK----------------------< -------------------------- HO_CO MMAND ------------------------------------------------ HO -COMMAND) included Sta rt T8 ----- SABM --- X ----- SABM --- X ----- SABM --- X
MC820 - CHANNEL_ACT ----------> < --- CHA_ACT_ACK -------Start T9113 Start T9113 MC821 X --- HO_ACCESS ----X ---- HO_ACCESS -----
T9113 expiry
MC643 Release of connection
1 4 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.
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
MC820
MC41b MC541a+MC81 MC541+MC81
MS ACCESS PB
Congestion BSS Pb Execution Attempt Radio (MS access problem) BSS Pb Success
1 4 38
MC820-MC821-(MC541+MC81) MC821 MC643 MC821-MC642-MC643 MC642

BSS PB
Incoming External HO - Indicators
1 4 39
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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)
Handover Preparation:
No detail available, only generic "preparation failures"
Handover Execution:
HO_Out_MSC_required
HO_Out_MSC_request
HO_Out_MSC_prep_fail
(deduced)
HO_Out_MSC_success
HO_Out_MSC_ROC HO_Out_MSC_drop_radio
HO_Out_MSC_drop_BSS
(deduced)
1 4 40
Outgoing External HO - Radio Failure with ROC
MS
serving_cell
BSC
MSC
BSC
target_cell
MS
- MEAS_R EPORT -> ------- MEAS_RESULT --------> EQUIRED -------> M C645A ---- HO_R ----------CR (HO_REQUEST) -------------------> < -------- CC --------------------------------------< ----- HO_REQUEST_ACK----------------------(HO-COMMAND) included < -------------------------- HO_COMMAND -----------------------------------------------Start T8 MC650 ----- SABM --------> < --- UA ------------- -- ESTABLISH_INDICATION-> ----- HO_FAILURE (reversion to old channel) ------------------------------------------> MC647 - CHANNEL_ACT ----------> < --- CHA_ACT_ACK -------Start T9113
X --- HO_ACCESS ----X ---- HO_ACCESS -----
----- CLEAR_COMMAND ----------------------> Radio interface fail : Reversion to old channel
Release of connection
1 4 41
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_R EPORT -> ------- MEAS_RESULT --------> M C645A ---- HO_REQ UIRED -------> ----------CR (HO_REQUEST) -------------------> < -------- CC --------------------------------------< ----- HO_REQUEST_ACK----------------------(HO -COMMAND) included < -------------------------- HO_COMMAND -----------------------------------------------Sta rt T8 MC650 ----- SABM --- X ----- SABM --- X ----- SABM --- X T8 expiry ----- CLEAR_REQ UEST -> MC648 Radio interface message fail Release of connection - CHANNEL_ACT ----------> < --- CHA_ACT_ACK -------Start T9113
1 4 42
Outgoing External HO - Counters

REQUEST
ATTEMPT
Preparation Failure
SUCCESS
Execution Failure CONGESTION
BSS PB
OUTGOING EXTERNAL Handover Preparation Request Any preparation failure Execution Attempt Reversion old channel Drop radio BSS Pb Success
1 4 43
MC645A MC645A-MC650 MC650
REVERSION OLD CHANNEL DROP RADIO BSS PB
MC647 MC648 MC650-MC646-MC647-MC648 MC646

Outgoing External HO - Indicators
1 4 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 1 1 1 incoming external HO success outgoing external HO success incoming external HO failure outgoing external HO failure
1 4 45
5 Handovers QoS per Adjacency
1 4 46
Type 180 Counters

Some handover indicators available per couple of (serving, target) cells permanently through PM type 180 counters
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
b
C40i(a,b) C40i(c,b)
a d e
C40i(f,d)
c
C40i(c,d)
both internal and external inter cell handovers are counted both SDCCH and TCH handovers are counted
1 4 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:
100
Cell B
Cell A
10 300
150 200 220
Cell C Fill up
Matrix Inc allocated Matrix Inc efficiency Matrix Inc unsuccess rate rate rate
Fill up
Serv - Tgt Cell A - Cell B Cell A - Cell C Cell B - Cell A Cell B - Cell C Cel C - Cell A Cell C - Cell B Matrix Inc request 100 10 150 220 300 200 30 30 Matrix Inc allocated 80 10 Matrix Inc success 40 10
80/100 100%
40/80 100%
(100-40)/100 100%
10%
100%
90%
1 4 48
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)
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 4 49
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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 Serving
C72i(S,Te)
C720 Outgoing TCH handover attempts C721 Outgoing TCH handover successes.
Tc
C72i(S,Tc)
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 C725 Outgoing TCH handover for a better cell cause C727 Outgoing TCH handover for a traffic cause
Te Tf
C728 Outgoing TCH handover for FDR
1 4 50
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 Target
C73i(Se,T)
C731 Incoming 2G TCH handover successes. C733
Sc
C73i(Sc,T)
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 C738 Incoming 2G TCH handover for FDR
Se Sf
C738 Incoming 2G TCH handover with unknown or missing causes
1 4 51
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 4 52
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: Handover Statistics > HO Statistics per couple of cells > Indicators with counter type 27
6 Inter-PLMN and Inter-RAT
1 4 53
Inter-PLMN HO Description
Since B8, outgoing inter-PLMN HO are available (incoming were always available) Usage of CGI in 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. Inter-PLMN external cells are defined by their CGI
Outgoing
Incoming
1 4 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.
Inter-PLMN Indicators
RTCH_HO_Inc_InterPLMN_request
RTCH_HO_Inc_InterPLMN_request_ratio
RTCH_HO_Inc_InterPLMN_allocated
RTCH_HO_Inc_InterPLMN_success
RTCH_HO_Out_InterPLMN_request
RTCH_HO_Out_InterPLMN_attempt
RTCH_HO_Out_InterPLMN_success
1 4 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_allocated HO_Inc_MSC_3G_2G_TCH request_emergency
HO_Inc_MSC_3G_2G_TCH_fail_3Gcong HO_Inc_MSC_3G_2G_HOreject_HL_Time
HO_Inc_MSC_3G_2G fail_prep_System
HO_Inc_MSC_3G_2G_success
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
HO_Out_MSC_2G_3G failure_radio
HO_Out_MSC_2G_3G drop_BSS
1 4 56
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 4 57
Handover Cause Distribution

Indicator Formulae Threshold Com men ts Ref. name Unit
HO cause distribution
(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%
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 4 58
Handover Standard Cause Distribution

Indicator Distribution HO cause standard Formulae
(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)
Threshold
Com men ts
Ref. name
Unit
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 4 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"
Handover Cause Distribution

HANDOVER CAUSE rates
1 4 60
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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
GHOORSUR
Unit %
Efficiency rate (also called execution success rate) of Outgoing HO : Rate of successful outgoing external and internal intercell SDCCH and TCH HO
Thres hold
90%
Indicator HO_Out_efficiency_rate
Formulae HO_Out_success/HO_Out_request
Comments
This indicator takes into account HO execution only (not HO preparation).
Ref. name
GHOOREFR
Unit %
1 4 61
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 HO_Out_request is incremented whenever the 44.018 HANDOVER COMMAND is sent on the Abis.
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
90%
Comments
Ref. name GHOIRSUR
Unit %
Success rate of execution of Incoming HO : Rate of successful incoming external and internal intercell SDCCH and TCH HO
Thres hold
90%
Indicator HO_Inc_efficiency_rate
Formulae HO_Inc_success / HO_Inc_allocated
Comments
Excluding congestion failures and BSS preparation failures from requests.
Ref. name GHOIREFR
Unit %
1 4 62
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 4 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.
15

Module 5 Directed Retry Indicators
Blank Page
152
GSM QoS Monitoring Directed Retry Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Module Objectives
Describe the counters and indicators used for monitoring the efficiency of the directed retry feature
153
154
Table of Contents
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 Self-assessment on the Objectives End of Module Page 7 8 9 10 11 12 13 14 15 16 17
155

156
1 Directed Retry Definition
157
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
158
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
159
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 5 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
Synchronous
ANNEX 3
between 2 cells sharing the same clocks collocated usually 2 sectors of the same BTS
tunable at OMC-R level
External
between two cells of different BSCs also called inter BSC
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 5 11
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 MC153 Detection of possible DR with neighbour
Same message flow as a Handover
MC717a MC142e/f then, SDCCH released in the serving cell

1 5 12
All Rights Reserved Alcatel-Lucent 2010 GSM QoS Monitoring Directed Retry Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
End with Assignment Complete (not "HO Performed")
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)
2 Queuing and (F)DR Indicators
1 5 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)
200 180 160 140 120 100 80 60 40 20 0
16 /0 5/ 20 09 17 22 /0 5/ 22 20 :0 09 17 0 00 /0 5/ 00 20 :0 09 17 0 /0 02 5/ 02 20 :0 09 17 0 04 /0 5/ 04 20 :0 09 17 0 06 /0 5/ 06 20 :0 09 17 0 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 16 /0 5/ 16 20 :0 09 17 0 18 /0 5/ 18 20 :0 09 0 20 20 :0 0
120.0% 100.0% 80.0% 60.0% 40.0% 20.0% 00.0% % Rejected Timeout Success % Success
nb
1 5 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 1200 1000 nb 800 600 400 200 0 16/05/2009 22 22:00 16/05/2009 23 23:00 17/05/2009 00 00:00 17/05/2009 01 01:00 17/05/2009 02 02:00 17/05/2009 03 03:00 17/05/2009 04 04:00 17/05/2009 05 05:00 17/05/2009 06 06:00 17/05/2009 07 07:00 17/05/2009 08 08:00 17/05/2009 09 09:00 17/05/2009 10 10:00 17/05/2009 11 11:00 17/05/2009 12 12:00 17/05/2009 13 13:00 17/05/2009 14 14:00 17/05/2009 15 15:00 17/05/2009 16 16:00 17/05/2009 17 17:00 17/05/2009 18 18:00 17/05/2009 19 19:00 17/05/2009 20 20:00 17/05/2009 21 21:00 90.00% 80.00% 70.00% 60.00% 40.00% 30.00% 20.00% 10.00% 0.00% % 50.00% Fail BSS Fail Radio ROC Prep Fail Success % Success
1 5 15
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.

1 5 16
End of Module Directed Retry Indicators
1 5 17
16

Module 6 Radio Measurement Statistics Indicators
Blank Page
162
GSM QoS Monitoring Radio Measurement Statistics Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
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
163
164
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 RMS Data Presentation 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 7.1 Suspecting a Voice Quality Problem All Rights 1 6 5 7.2 Suspecting a Cell Coverage ProblemReserved Alcatel-Lucent 2010 GSM QoS Monitoring Radio Measurement Statistics Indicators EVOLIUM Base Station Subsystem 1 B10 Introduction to Quality of Service and Traffic Load Monitoring Exercise BSS Exercise 2 7.3 Suspecting a Cell Interference Problem Exercise 3 Exercise 4 Exercise 5 8 Additional Information RMS Counters Self-assessment on the Objectives 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
166
1 Radio Measurement Statistics Objectives
167
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 of bad QoS Help logical parameters fine tuning
168
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
169
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.
2 RMS Implementation in the BSS
1 6 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 6 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 for 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 6 12
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
1 6 13
Templates
A9159 NPO Software application

PM
The cell profile can be: micro, indoor, multiband, etc. The cell class can be: rural, urban, rural rapid (covering express railway), etc.
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
4 OMC-R 1
Template
PM
5 NPO
QOS
1 6 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).
RMS Data Presentation

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 6 15
3 RMS Data
1 6 16
3 RMS Data
RMS Data Presentation

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 6 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.
4 Call Quality Statistics per TRX
1 6 18
4.1 Generalities
Suspecting a Voice Quality problem
Percentage of Noisy calls
1 6 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 CALL
480ms
end
CQS1
CQS2
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 Multiframes

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 6 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. Default value of VQ_AVERAGE is 6 SACCH mfr but in the example above it has been considered to be set to 4 Samfr. 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
0 -110
1 6 21
Level (dBm)
VQ_RXLEV
-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 6 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 6 23
All these parameters are included in the RMS PM Type 31 result files as RMS counters: 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 6 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 6 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 6 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 measurements on the uplink path VQ_ABNORMAL_BAD_FER = RMS18 Number of calls with fair quality measurements but with bad FER measurements on the uplink path
1 6 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_QUALITY_UL_SAMPLES = INTERFERED_UL_SAMPLES + BAD_COVERAGE_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL 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_QUALITY_UL_SAMPLES = INTERFERED_UL_SAMPLES + BAD_COVERAGE_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL 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
5 Radio Quality Statistics per TRX
1 6 28
5.1 Generalities
Suspecting a TRX hardware problem
Average path balance
1 6 29
These RMS indicators are provided on the NPO tool per TRX, per Cell: 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 6 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 TMR_RXQUAL_UL_RXLEV_UL
1 6 31
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 Radio Quality Statistics: 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 6 32
All these parameters are included in the RMS PM Type 31 result files as RMS counters: 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 asymmetric DL loss (external combiner) or UL gain (TMA) will have an impact on the UL and DL path loss measurements that must be taken into account when interpreting the RMS results for path loss and path balance.
5.2 Radio Quality Parameters [cont.]

RMS Parameters Radio Quality Statistics:
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 6 33
All these parameters are included in the RMS PM Type 31 result files as RMS counters: 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: decremented by 1 by the BTS each time an SACCH measurement from the mobile cannot be decoded (SACCH_BFI=1). 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) 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 Radio Quality Statistics:
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)
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
S A C C H
SACCH mfr
S A C C H
S A C C H
S A C C H
Sf 1
Sf 2
Sf 3
Sf 4
Sf 5
Sf 6
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
1 6 34
All these parameters are included in the RMS PM Type 31 result files as RMS counters: 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 6 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: 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.3 Radio Quality Counters [cont.]

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 6 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: S(RXQUAL i, RXLEV band j) x Max j / 254 TPR_RXQUAL_DL_RXLEV_DL(i,j) x TMR_RXQUAL_DL_RXLEV_DL(j) / 254

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 6 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

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 6 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

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 6 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 Radio Quality Statistics 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 0 0 1 0 0 0 1 1 1 1 0 0 1 1 0 1 1 1 0 1 0 1 1
BFI
0
Sf 1 Sf 2
Sf 3 Sf 4 Sf 5 Sf 6
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 0 0 0 0 0 0 0 1 2 3 3 3 3 4 4 4 5 6 6 6 6 6 7 7
RxLev UL
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
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 6 40
All Rights Reserved Alcatel-Lucent 2010 GSM QoS Monitoring Radio Measurement Statistics Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
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 for AMR Monitoring Radio Quality Statistics 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 6 41

RMS Counters for AMR Monitoring Radio Quality Statistics 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 6 42

RMS Counters for AMR Monitoring Radio Quality Statistics 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 6 43
AMR-FR codec usage compared to RXLEV
RXLEV UL bands are defined as follows:

RMS Counters for AMR Monitoring Radio Quality Statistics
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 6 44
AMR-HR codec usage compared to RXLEV
RXLEV UL bands are defined as follows:

RMS Counters for Timing Advance Radio Quality Statistics
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 6 45
Corresponding RMS counter numbers: RMS36 = PERC_TA_GT_TA_STAT RMS37 = MAX_TA

RMS Counters for Timing Advance 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 6 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.

RMS Counters for Timing Advance A new set of RMS counters related with timing advance analysis. Uplink :
TPR_UL_RXQUAL_TA_BAND = RMS53 : Vector of 10 cells containing the average UL RxQual measured for each TA band (1 cell per TA band)
Downlink :
TPR_DL_RXQUAL_TA_BAND = RMS54 : Vector of 10 cells containing the average DL RxQual measured for each TA band (1 cell per TA band)
1 6 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).

RMS Counters for Timing Advance 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 6 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-UnbalancedOutput-Power 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 6 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 6 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 6 51
All these parameters are included in the RMS PM Type 31 result files as RMS counters: 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 6 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 6 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 always be part of the EMO-frequency list.
7 RMS Indicators Usage
1 6 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 6 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. 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 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 6 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. These RMS indicators are provided on the NPO tool per TRX, per Cell: 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 6 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.
1 6 58
Exercise 2
Interpret this graph.
1 6 59
7.3 Suspecting a Cell Interference Problem

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 6 60
These RMS indicators are provided on the NPO tool per TRX, per Cell: 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
Average DL RxQuality = 2.81
Average RxQual value per RxLev band has also to be considered

1 6 61
Exercise 4
1 6 62
Exercise 5
1 6 63
Rapport NPO : Alc_Mono_Carrier_over_interference
8 Additional Information
1 6 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 6 65
Corresponding RMS counter numbers: 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 6 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 6 67
Corresponding RMS counter numbers: RMS23 = IND_CI_PARTIAL_OBSERVATION RMS24 = IND_CI_OVERFLOW

1 6 68
End of Module Radio Measurement Statistics Indicators
1 6 69
17

Module 7 Traffic Indicators
Blank Page
172
GSM QoS Monitoring Traffic Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Module Objectives
Describe BSS traffic indicators used for radio resource dimensioning
173
174
Table of Contents
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 Speech Coding Version All Rights Reserved Alcatel-Lucent 2010 1 7 5 Distributions GSM QoS Monitoring Traffic Indicators EVOLIUM Base Station Subsystem BSS B10 Introduction Indicators and Traffic Load Monitoring 4 Resource Occupancy to Quality of Service 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 Self-assessment on the Objectives End of Module Page 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

176
1 Call Mix Definition
177
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.)
178
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
179
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 : 900 (2/3 TC) 4 1.5 (2/3 internal, 1/3 external) 11 % 5% 6000 90 seconds 4.2 seconds
1 7 10
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 7 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 too too too many LU/Calls: SDCCH congestion, TCU load, MSC overload many HO/calls: speech quality, call drop, DTC load many calls: TCH congestion many paging: DTC processor load, PCH congestion
1 7 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 redimensioning.
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 7 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?
1 7 14
2 Basis of Traffic Theory
1 7 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 7 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 7 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 7 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 %)
1 7 19
Pblock (Blocking probablity) : Probability that a resource request may be rejected by the system due to insufficient resource availability at the moment of the request. 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 7 20
Erlang B Abacus
1 7 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 7 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 => => T = 0.6 E 50% Traffic less!!
1 7 23
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 7 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 7 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 7 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 7 27
Exercise
Complete the form to get less than 2% of blocking.
cell 12, 743
call mix info
Erlang T CH Offered traffic
traffic forecast
proposed config
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% 330 call/ hour mean TCH call duration 129 sec blocking rate 4% 600 call/ hour mean TCH call duration 96 sec blocking rate 8 % 30 % offered traffic increase
12,675
12,865
30 % offered traffic increase
1 7 28
3 TCH Resource Allocation Indicators
1 7 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 7 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 7 31
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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 7 32
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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 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 7 33
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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
4 Resource Occupancy Indicators
1 7 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 7 35
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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)
35 30 25 20 Er 15 10 5 0
35 30 25 20 Er 15 10 5 0 half Erl total full Erl total RTCH Erl total
1 7 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
16 /0 16 5/2 /0 00 17 5/2 9 2 /0 00 2 17 5/2 9 2 22: / 0 0 0 3 00 17 5/2 9 0 23: / 0 0 0 0 00 17 5/2 9 0 00: / 0 0 0 1 00 17 5/2 9 0 01: / 0 0 0 2 00 17 5/2 9 0 02: / 0 0 0 3 00 17 5/2 9 0 03: / 0 0 0 4 00 17 5/2 9 0 04: / 0 0 0 5 00 17 5/2 9 0 05: / 0 0 0 6 00 17 5/2 9 0 06: / 0 0 0 7 00 17 5/2 9 0 07: / 0 0 0 8 00 17 5/2 9 0 08: / 0 0 0 9 00 17 5/2 9 1 09: / 0 0 0 0 00 17 5/2 9 1 10: / 0 0 0 1 00 17 5/2 9 1 11: / 0 0 0 2 00 17 5/2 9 1 12: / 0 0 0 3 00 17 5/2 9 1 13: / 0 0 0 4 00 17 5/2 9 1 14: / 0 0 0 5 00 17 5/2 9 1 15: / 0 0 0 6 00 17 5/2 9 1 16: / 0 0 0 7 00 17 5/2 9 1 17: / 0 0 0 8 00 17 5/2 9 1 18: / 0 0 0 9 00 5/ 9 19 20 20 :0 09 2 0 21 0:0 21 0 :0 0
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 7 37
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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
5 Traffic Model Indicators
1 7 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% 80% 70% 60% nb 50% 40% 30% 20% 10% 0%
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 08 17 /0 08 5/ :0 20 0 09 10 17 /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
LCS Other IMSI detach Suppl Service SMS LU FOR Location Update MOC
1 7 39
16 /0 5/ 20
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 7 40
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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 60% nb 40% 20% 0% AMR DR_EFR DR FR
1 7 41
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 12 17 /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
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 7 42
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: Traffic Load and Traffic Model > SDCCH traffic > MS penetration rate Traffic Load and Traffic Model > TCH traffic > Speech version and Channel type [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 EGSM 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 7 43
Report : Alc_Mono_SDCCH_traffic
TCH traffic indicators
1 7 44
Report : Alc_Mono_RTCH_traffic
6 Preemption Indicators
1 7 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 7 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 7 47
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: 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 7 48
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: GLOBAL Quality of service INDICATORS> RTCH > Preemption feature

1 7 49
End of Module Traffic Indicators
1 7 50
18

Module 8 Case Studies
Blank Page
182
GSM QoS Monitoring Case Studies EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Module Objectives
Analyze with the KPI QoS some typical problems
183
184
Table of Contents
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 Self-assessment on the Objectives End of Module Page 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
185

186
1 Congestion
187
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 %
188
2 Sector Problem
189
2 Sector Problem
Scetor Problem Analysis

In this trisectorised site, give the worst sector. What can you propose to do?
1 8 10
3 QSCSSR
1 8 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 9 0 1 43 663 88 84 Paris_City_S3 4 0 2 924 1352 1455 1430
Counter MC138 MC07 MC137 MC01 MC02 MC140a MC718
Definition SDCCH drops on SDCCH established phase due to Radio Link Fail. SDCCH drops during any outgoing SDCCH handover SDCCH drops in SDCCH established phase due to BSS problem SDCCH assign success for Mobile Terminating procedure SDCCH assign success for Mobile Originating procedure normal assignment requests for TCH establishment (HR or FR) TCH normal assignment successes (HR or FR)
QSCSSR=?
1 8 12
4 Quality
1 8 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 8 14
5 RMS Level
1 8 15
5 RMS Level
RMS Level Analysis

Find the 2 worst cells in the table. Try to propose a solution!
1 8 16
6 Interference
1 8 17
6 Interference
Interference Analysis
Find 1 bad cell with some HO problem. What can you propose to do?
1 8 18
7 BSS Problem
1 8 19
7 BSS Problem
BSS Problem Analysis

What is the worst cell? Propose some probable solutions.
1 8 20

1 8 21
End of Module Case Studies
1 8 22
19

Module 9 Annexes
3JK11051AAAAWBZ Issue 01
All Rights Reserved Alcatel-Lucent 2010 3JK11051AAAAWBZ Issue 01 Section 1 Module 9 Page 1
Blank Page
192
GSM QoS Monitoring Annexes EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
Module Objectives
Describe List Explain Identify ...
193
194
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 Outgoing External DR - Indicators All Rights Reserved Alcatel-Lucent 2010 195 GSM QoS Monitoring Annexes Protocol Stacks 4Base Station BSS BSS B10 Introduction to Quality of Service and Traffic Load Monitoring GSM Subsystem EVOLIUM 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 Positioning Methods: CI+TA Positioning 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

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 Algorithm Cause 11 Handover Algorithms Cause 13 Outgoing Intercell Handovers from Concentric Cell Incoming Intercell Handovers towards Concentric Cell Self-assessment on the Objectives End of Module Page 74 75 77 78 79 80 81 83 84 85 86 87 93 94 96 97
196
1 Radio Measurement Reporting
197
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
198
Radio Measurement Mechanisms [cont.]

For each MS connected to the BTS (TCH or SDCCH)
Meast Report
Meast Result
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
199
Measurement Result Message
L1 Info
L3 Info Measurement Report From the MS
Back
1 9 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 a neighboring cell.
2 Extended Measurement Reporting (MAFA)
1 9 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 9 12
Extended Measurement Reporting Mechanisms

MS BTS BSC TCH ASSIGNMENT PHASE (OC or TC) MSC
< ----------------------------------ASSIGNMENT REQUEST < -------------------------------------------------------PHYSICAL CONTEXT REQUEST -------------------------------------------------------- > PHYSICAL CONTEXT CONFIRM < -------------------------------------------------------CHANNEL ACTIVATION (TCH) (EMO included) -------------------------------------------------------- > CHANNEL ACTIVATION ACKNOWLEDGE . . TCH establishment. . ------------------------------------------------------- > ASSIGNMENT COMPLETE
--------TCH---------> ASSIGNT 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 9 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.
3 Directed Retry Indicators
1 9 14
Internal DR - Success Case

MS serving cell target cell TCH ASSIGNMENT PHASE (OC or TC) < ----------------------ASSIGNMENT REQUEST Queuing allowed BSC MSC
No free TCH TCH request queued Start T11 ----------------------- > QUEUING_INDIC. MC13A IDR condition met MC153, MC144e,
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.
CHANNEL ACTIV. (TCH) <---------------------------------- MC15A CHAN ACTIV ACK ----------------------------------> HO CMD HANDOVER COMMAND <---------------------- <------------------------------------------------------------------------ start T3103 (SDCCH) C154, MC607 start T3124 HANDOVER ACCESS ------------------------(TCH)----------------------------> -------------------------------------------------------------> PHYSICAL INFORMATION <------------------------------------------------------------stop T3124 start T200 ------------------------ SABM --------------------------> <-------------------------- UA ----------------------------stop T200 HANDOVER COMPLETE -------------------------------------------------------------> C145A+C145C
HO DETECTION ----------------------------------> start T3105
stop T3105 ESTABLISH INDICATION ----------------------------------> HO CMP stop T3103 ----------------------------------> ASSIGNMENT COMPLETE ------------------------> Release of old SDCCH MC151,MC717A, MC142e
MCx counters belong to Standard Type 110 reported permanently Cx counters belong to Detailed Type 29 reported on demand Standard type from B8
1 9 15
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
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 9 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 TCH ASSIGNMENT PHASE (OC or TC) < ---------------------------------------------------ASSIGNMENT REQUEST Queuing allowed Start T11 --------------------------------------------------- > QUEUING_INDIC. MC13A IDR condition met No free TCH In target cell MC153, MC144e,MC607 MC555
Standard Type
1 9 17
C155 is available in Type 29.
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 PHYSICAL INFORMATION ----------------------------------> <------------------------------------------------------------- start T3105 SABM -------------------------------------------------------------> ESTABLISH INDICATION UA ----------------------------------> <------------------------------------------------------------- stop T3105 HANDOVER COMPLETE ----------------------------------------------------- - - - -X MS serving cell target cell BSC SABM MEAS REP -----------------------> ESTABLISH INDICATION -----------------------> MEASUREMENT RESULT UA ------------------------------------------------------------------------> ------------------------------------------------------------------------> <----------------------CHANNEL ACTIVATION HO FAILURE HANDOVER FAILURE <--------------------------------------------------------> ------------------------------------------------------------------------> C152 CHANNEL ACTIV ACK ----------------------------------> Release of new channel
MSC
HO CMD HANDOVER COMMAND <----------------------- <------------------------------------------------------------------------ start T3103 C154 SABM -----------x T3103 expiry C152
1 9 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
Preparation Failure
SUCCESS
Execution Failure CONGESTION
INCOMING INTERNAL Directed Retry Preparation Request Congestion BSS Pb Execution Attempt Radio (MS access problem) BSS Pb Success
1 9 19
MC153, C153 MC555, C155 C153-C154-C155 C154

BSS PB
BSS PB
MS ACCESS PB
C152 C154-C151-C152 MC151, C151
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) BSS problem (no specific counter)
DR Execution:
1 9 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 PHYSICAL INFORMATION ----------------------------------> <------------------------------------------------------------- start T3105 SABM -------------------------------------------------------------> ESTABLISH INDICATION UA ----------------------------------> <------------------------------------------------------------- stop T3105 HANDOVER COMPLETE ----------------------------------------------------- - - - -X SABM -----------------------> ESTABLISH INDICATION UA ------------------------------------------------------------------------> <----------------------HO FAILURE HANDOVER FAILURE -----------------------> ------------------------------------------------------------------------> Release of new channel
start T3103 MC144E C144A or C144C
C144A, C143A: Forced DR C144C,C143E: Normal DR
C143A or C143E
1 9 22
Outgoing Internal DR - Radio Failure Drop

DR FAIL. CASES > Outgoing internal DR fail: drop
MS
serving cell
target cell
BSC
MSC
HO CM D HAND O VER CO M MAND <----------------------- <------------------------------------------------------------------------ start T3103 M C144E SABM C 144A or C144C ----------x
C144A,C143B: Forced DR C144C,C143F: Normal DR
T3103 expiry C 143B or C143F ------------------------> ASSIG NMENT FAILURE Radio interface m essage failure Release of SDCCH and TCH
1 9 23
Counters C144A, C143B, C144C, C143F are type 29.
Outgoing Internal DR - Counters

DR FAIL. CASES > Outgoing internal DR counters
REQUEST
ATTEMPT
Preparation Failure
SUCCESS
OUTGOING INTERNAL Directed Retry
Execution Failure
CONGESTION
BSS PB
Preparation Request Any preparation failure Execution Attempt Reversion old channel Drop radio BSS Pb Success
1 9 24
MC144E, C144A+C144C
REVERSION OLD CHANNEL

(C144A+C144C) - (C145A+C145C) C145A+C145C C143A+C143E C143B+C143F (C145A+C145C) - (C143A+C143E+C143B+C143F) MC142E, C142A+C142C
DROP RADIO BSS PB
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS Specific indicators for densification techniques > Directed Retry > Outgoing DR DROBSUR: global efficiency of outgoing internal DR = MC142E/MC144E Other indicators can be computed from Type 29 counters: 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 DRFOSUEN DROBSUIN DRFORDIN DRFORDEN DROBRDIN DROBRQIN C142a C142b C142c C144a C144b C144c C145c NB_OUT_FORCED_IDR_SUCC NB_OUT_FORCED_EDR_SUCC NB_OUT_NOR_IDR_SUCC NB_OUT_NOR_EDR_SUCC NB_OUT_FORCED_IDR_REQ NB_OUT_FORCED_EDR_REQ NB_OUT_NOR_IDR_REQ NB_OUT_NOR_EDR_REQ NB_OUT_NOR_IDR_ATPT NB_OUT_NOR_EDR_ATPT
DROMSUEN C142d
DROMRDEN C144d DROMRQEN C145d
External DR - Success
DR FAIL. CASES > External DR > successful case
MS se rvin g_ce ll BSC MSC < ------ASSIGNT R EQUEST------TCH request queued
------ HO_REQUIRED ----------> EDR condition met MC144F
BSC
ta rge t_ce ll
MS
----------CR (HO_REQUEST) -----> < --------- CC -----------------------< ----- HO_REQUEST_ACK -------(HO_COMMAND)
MC820 ---- CHANNEL_ACTIVATION ------> < - CHANNEL_ACT_ACK------------Sta rt T9113 MC821 < ---- HO_ACCESS ----< ---- HO_ACCESS ----< ------ HO_DETECTION--------------
< ------------------------- HO_COMMAND -----------------------------------------------------C145B+ C145D Sta rt T8 < -- HO_DETECTION --------------
--- PHYSICAL_INFO --> < --- SABM ------------------- UA -------------->
< ----- ESTABLISH_INDICATION ----
Relea se of SDCCH
< ---- CLEAR _COMMAND -----MC142F Cause : HO_SUCCESSFUL Stop T8
< ----------- 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 9 26
All Rights Reserved Alcatel-Lucent 2010 GSM QoS Monitoring Annexes EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring
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) BSS problem (no specific counter)
DR Execution:
1 9 27
Outgoing External DR - Radio Failure ROC

DR FAIL. CASES > Outgoing external DR fail: reversion old channel
MS se rving_ce ll BSC MSC BSC ta rge t_ce ll MS
ASSIGNT R EQUEST ---------------------> TCH request queued ---- HO_REQUIRED -------> EDR condition met MC144F
----------CR (HO_R EQUEST) -------------------> < -------- CC --------------------------------------< ----- HO_R EQUEST_ACK----------------------(HO-CO MMAND) included
- CHANNEL_ACT ----------> < --- CHA_ACT_ACK -------Start T9113
< -------------------------- HO_CO MMAND -----------------------------------------------Sta rt T8 C145B+ C145D ----- SABM --------> < --- UA ------------- -- ESTABLISH_INDICATION-> ----- HO_FAILURE (reversion to old channel) ------------------------------------------> C143C+ C143G
X --- HO_ACCESS ----X ---- HO _ACCESS -----
C145B,C143C: Forced DR C145D,C143G: Normal DR
----- CLEAR_COMMAND ----------------------> Radio interface fail : Reversion to old channel
R elease of connection
1 9 28
Outgoing External DR - Radio Failure Drop

DR FAIL. CASES > Outgoing external DR fail: drop
MS se rvin g_ce ll BSC MSC BSC ta rge t_ce ll MS
ASSIGNT R EQUEST --------------------->
TCH request queued ---- HO_R EQUIRED -------> EDR condition met MC144F
----------CR (HO_REQUEST) -------------------> < -------- CC --------------------------------------< ----- HO_REQUEST_ACK----------------------(HO-COMMAND) included
- CHANNEL_ACT ----------> < --- CHA_ACT_ACK -------Sta rt T9113
< -------------------------- HO_COMMAND -----------------------------------------------Sta rt T8 C145B+ C145D ----- SABM --- X ----- SABM --- X ----- SABM --- X C143D+ C143H C145B,C143D: Forced Radio interface message fail DR C145D,C143H: Normal DR T8 expiry ----- CLEAR _REQUEST -> Release of connection
1 9 29
Outgoing External DR - Counters

DR FAIL. CASES > Outgoing external DR counters
REQUEST
ATTEMPT
Preparation Failure
SUCCESS
Execution Failure
CONGESTION
OUTGOING EXTERNAL Directed Retry Preparation Request Any preparation failure Execution Attempt Reversion old channel Drop radio BSS Pb Success MC144F, C144B+C144D (C144B+C144D) - (C145B+C145D) C145B+C145D
BSS PB
REVERSION OLD CHANNEL DROP RADIO
C143C+C143G C143D+C143H (C145+C145D) - (C143C+C143G+C143D+C143H) MC142F, C142B+C142D
BSS PB
1 9 30
Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS Specific indicators for densification techniques > Directed Retry > Outgoing DR DROMSUR: global efficiency of outgoing external DR = MC142F/MC144F Other indicators can be computed from Type 29 counters: 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.
4 GSM BSS Protocol Stacks
1 9 32
Signaling Links
MSC BSC BTS BSC
A-Interface MT-Link signaling #7 System with SCCP
BSC BTS MS OMC-R
Abis Interface RSL with LAPD Protocol
Air-Interface (CCCH/SACCH/FACCH) with LAPDm Protocol
OML Link with X25 connection LAPB Protocol
1 9 33
The Reference Model
7 Application 6 Presentation 5 Session 4 Transport 3 Network 2 Data Link 1 Physical
User of Transport Service
Network Service
Transport Service
1 9 34
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 9 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 9 36
BSS Protocol Stacks
MS
BTS
BSC
MSC
PSTN ISDN
Air Intfc
Abis Intfc
A Intfc
B .. F Intfc
CM MM RR BSSAP RR BTSM SCCP LAPDm LAPDm LAPD LAPD MTP BSSAP
CM MM BSSAP LAYER 3
RR
SCCP MTP LAYER 2
digit radio
1 9 37
digit radio
64 kb/s
64 kb/s
64 kb/s
64 kb/s
LAYER 1
BSS Protocol Stacks [cont.]

(detailed)
(SMS) SS CC (Relay) MM DTAP RR RR 3 RR' 2 1 LAPDm
Phycal Layer
SS (SMS) CC (Relay MM DTAP BSS MAP SSCS SSTM 3 SSTM 2 PCM TS A MSC / VLR
SS (SMS)
MAP SSGT SSCS SSTM 3 SSTM 2 PCM TS (D)
MAP SSGT SSCS SSTM 3 SSTM 2 PCM TS
BSS MAP SSCS
BTSM LAPD
64 kbit/s or PCM TS
BTSM LAPD
64 kbit/s or PCM TS
SSTM 3 SSTM 2 PCM TS
LAPDm
Phycal Layer
Um
A bis
MS
BTS
BSC
(ex. : HLR)
NSS
1 9 38
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)
BSSAP
DTAP BSSMAP SCCP
User Data
Layer 1-3
MTP 1-3
1 9 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 9 40
GSM BSS Protocols [cont.]

Relationship between DTAP, CC, MM, BSSMAP, RR
Call Control (CC)
DTAP
MS
Radio Resource (RR)
BSS
BSSMAP
MSC
Back
1 9 41
5 LCS
1 9 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 9 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

1
Abis BSC
A
MSC
Lg
GMLC
Le
External LCS client
Where is my son?
Lb
MS GPS reference network
OSP
Lh
Abis
BTS
SMLC
SAGI
MFS
1 MS Request 2 Network Request 3 External Request
A-GPS server
HLR
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
LCS: Location Services SMLC: Serving Mobile Location Center GMLC: Gateway Mobile Location Center A-GPS: Assisted GPS
1 9 44
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)
MS BTS 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

BSSAP-LE Perform_Location_Response (failure)
MC923c
Failure
MC923d
BSSMAP Perform_Location_Response (failure) BSSMAP Perform_Location_Abort BSSAP-LE Perform_Location_Response
Success
MC923b
BSSMAP Perform_Location_Response Provide_Subscriber_Location Result LCS Service Response
BSSMAP Clear Command and Release
1 9 45
Four counters MC923a MC923b MC923c MC923d NB_LCS_REQ NB_LCS_SUCC NB_LCS_ABORT Number of location requests received from the MSC in CS domain. Number of successful location requests performed in a BSS. Number of location aborts received from the MSC in CS domain.
NB_LCS_FAIL_LB Number of location requests rejected by the SMLC.
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 AGPS, MS-Based A-GPS) and for different Error causes. See the next slide.
LCS Counters in MFS: QOS FOLLOW UP: P800: NB_LOC_REQ the P801: NB_ASSIST_DATA_REQ P802: NB_ASSIST_DATA_SUCC requested P803: NB_LOC_TA_SUCC P804: NB_LOC_CONV_GPS_SUCC P805: NB_LOC_MA_AGPS_SUCC P806: NB_LOC_MB_AGPS_SUCC Based P807: NB_LOC_TA_PCF_REQ P808: NB_LOC_TA_PCF_SUCC P809: NB_LOC_CONV_GPS_PCF_REQ PCF. P810: NB_LOC_MA_AGPS_PCF_REQ PCF. P811: NB_LOC_MA_AGPS_PCF_SUCC P812: NB_LOC_MB_AGPS_PCF_REQ P813: NB_LOC_MB_AGPS_PCF_SUCC Based P814: NB_LCS_PROTOCOL_ERROR Number of received LCS requests for MS positioning received from BSC Number of received LCS requests for GPS assistance data (initially requested by the MS) received from the BSC. Number of successful GPS assistance data delivery (initially by the MS) responses sent to the BSC. Number of successful location responses sent to the BSC using TA positioning method. Number of successful location responses sent to the BSC using Conventional GPS positioning method. Number of successful location responses sent to the BSC using MSAssisted A-GPS positioning method. Number of successful location response sent to the BSC using MSA-GPS positioning method. Number of location calculation attempts with TA positioning PCF. Number of location calculations successfully performed with TA positioning PCF. Number of location calculation attempts with Conventional GPS Number of location calculation attempts with MS-Assisted A-GPS Number of location calculations successfully performed with MS Assisted A-GPS PCF. Number of location calculation attempts with MS-Based A-GPS PCF. Number of location calculations successfully performed with MSA-GPS. 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 P818: NB_LCS_FAILURE_TIMER_EXPIRY P819: NB_LCS_FAILURE_INTERNAL P820: NB_UNKNOWN_LCS_REQ SMLC. P821: NB_LOC_CONV_GPS_PCF_SUCC Conventional GPS PCF. Number of failed LCS procedures due to RRLP problem. Number of failed LCS procedures due to LCS guard timer expiry. Number of failed LCS procedures due internal problem detected by the MFS/SMLC. Number of LCS requests rejected because not supported by the Number of location calculations successfully performed with
PCF: Positioning Calculation Function POSITION AVERAGE USED ON RNO: Values are given in minutes LATITUDES AND LONGITUDES: P822: AV_TA_LAT P823: AV_TA_LONG P824: AV_CONV_GPS_LAT P825: AV_CONV_GPS_LONG P826: AV_MA_AGPS_LAT P827: AV_MA_AGPS_LONG P828: AV_MB_AGPS_LAT P829: AV_MB_AGPS_LONG Average of latitudes for TA Method Average of longitudes for TA Method Average of latitudes for Conventional GPS Method Average of latitudes for Conventional GPS Method Average of latitudes for MS-Assisted A-GPS Method Average of longitudes for MS-Assisted A-GPS Method Average of latitudes for MS-Assisted A-GPS Method 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 Method P831: ST_DEV_TA_LONG Method P832: ST_DEV_CONV_GPS_LAT Conventional P833: ST_DEV_CONV_GPS_LONG P834: ST_DEV_MA_AGPS_LAT Assisted P835: ST_DEV_MA_AGPS_LONG Assisted P836: ST_DEV_MB_AGPS_LAT Assisted P837: ST_DEV_MB_AGPS_LONG Assisted Standard deviation of the latitude of MS obtained with TA Standard deviation of the longitude of MS obtained with TA Standard deviation of the latitude of MS obtained with GPS Method Standard deviation of the longitude of MS obtained with Conventional GPS Method Standard deviation of the latitude of MS obtained with MS A-GPS Method Standard deviation of the longitude of MS obtained with MS A-GPS Method Standard deviation of the latitude of MS obtained with MS A-GPS Method Standard deviation of the longitude of MS obtained with MS 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 9 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-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 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 A-GPS : Assisted GPS GMLC : Gateway Mobile Location Center LCS : Location Services SMLC : Serving Mobile Location Center
1
Where am I?
BTS
Abis
2
Emergency call
A
3
OSP GMLC
Lh
Where is the accident?

Lg
Where is my son?
Le
BSC
Abis
MSC
External LCS client
BTS
Lb
HLR
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 SMLC
SAGI
A-GPS server
1 9 49
GPS receivers reference network
5 LCS
LCS Positioning Procedure
Provide subscriber location 5
BTS BSC
Paging, authentication, ciphering, notification 4
MSC
Provide subscriber location 3
OSP GMLC
Location request 1
BTS
6 Individual positioning
Location report
2 Routing information
8 Location response
MFS SMLC
HLR
1 9 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 ongoing 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
Target MS RRLP (04.31)
BSC
SMLC (MFS) RRLP (04.31)
Relay RR (04.18) BSSLAP RR BSSAP-LE L2 (LAPDm) L1 L2 (LAPDm) L1 L2-GSL L1-GSL
BSSLAP (08.71) BSSAP-LE (09.31) L2-GSL L1-GSL
Um
Lb
1 9 51
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 Provide_Subscriber_Location Paging Authentication + Ciphering BSSMAP Perform_Location_Request
Starts T_Location
Adequate positioning method chosen by SMLC with optional additional scenario
BSSAP-LE Perform_Location_Response BSSMAP Perform_Location_Response
Stop T_Location
Provide_Subscriber_Location Result LCS Service Response
MSSMAP Clear Command and Release
1 9 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 on-going), 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 accuracy, the response time category (Low Delay or Delay Tolerant), Current Cell Id + TA information are always provided to the SMLC. The time of transfer of the assitance data on the SDCCH is estimated about 14s for a 1000 octets information.
5 LCS
Positioning Methods: CI+TA Positioning

Principles of CI + TA Positioning Method
LCS_LATITUDE
3dB point given by the azimuth and the HPBW
HALFP WR
_B
EA M
_W
LCS_AZIMUTH (Main Beam Direction given by the azimuth) MS estimated location
ID
TH
TA
LCS_LONGITUDE
553 m
g vin Ser
ce ll ( CI)
3dB point given by the azimuth and the HPBW

1 9 53
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:
s
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 method
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 Perform Location Request
SMLC
Location Request
Measurement Position Request
(X,Y) Location Response
Measurement Position Response (X,Y) Perform Location Response (X,Y)
(X,Y): computed position
1 9 54
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
A-GPS server
GPS receivers reference network
1 9 55
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 SMLC A-GPS Server
Perform Location Request
GPS info Request GPS info Response
Location Request
Assistance Data Assistance Data Acknowledge
Assistance Data
Positioning calculation: latitude, longitude and altitude
Position Request (X,Y) Position Response Location Response
Measurement Position Response (X,Y)

1 9 56
Perform Location Response (X,Y)
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 SMLC A-GPS Server
GPS info Request GPS info Response
Location Request
Assistance Data Assistance Data Acknowledge
Assistance Data
Pseudo-range measurements (M)
Position Request Position Response Location Response
Measurement Position Response (M)
GPS Location Request (M) Perform Location Response (X,Y) GPS Location Response (X,Y)

1 9 57
(X,Y)
Using a reduced set of assistance data, the MS makes pseudorange measurements and sends the result to the A-GPS server, which fixes the position in the end.
5 LCS
LCS Impact on HO
HO preparation
Inhibition of better cell handovers Other HO
LCS Service Request Send_Routing_Info request Send_Routing_Info response Provide_Subscriber_Location Paging Authentication + Ciphering BSSMAP Perform_Location_Request
Starts T_Location
Emergency HO detection
BSSLAP - Reset
1 9 58
HO needed during LCS procedure.
5 LCS
LCS Impact on HO [cont.]

HO management
Internal HO
Intra BSC HO on going

BSSMAP Perform_Location_Request BSSAP-LE Perform_Location_Response BSSLAP - Reset
HO complete
BSSMAP perform location response (cause = "Intra-BSC Handover Complete)
1 9 59
Mobile in communication
5 LCS
LCS Impact on HO [cont.]

HO management
External HO
MS BTS Serving BSC SMLC MSC GMLC HLR LCS client
External BSC HO
BSSMAP HO required
BSSAP-LE Perform_Location_Abort BSSAP-LE Perform_Location_Response
BSSAP-LE Perform_Location_Response
1 9 60
5 LCS
BSS Parameters
FLAGS
EN_LCS EN_SAGI
OPTIMIZATION DATA
ARC_SIZE_FACTOR MIN_RADIUS_FACTOR MAX_RADIUS_FACTOR
Timers
T_Location T_Location_longer T_Loc_Abort T_LCS_delay_tolerant T_LCS_LowDelay T_RRLP_low_delay T_RRLP_delay_tolerant
1 9 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, MS-Assisted 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
EN_CONV_GPS EN_MS_ASSISTED_AGPS EN_MS_BASED_AGPS
SITE DATA
LCS_LATITUDE LCS_LONGITUDE LCS_SIGNIFICANT_GC LCS_AZIMUTH HALF_POWER_BANDWIDTH
1 9 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?
1 9 63
5 LCS
Positioning Methods: CI+TA Positioning

Ellipsoid arc definition:
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
North
Point (O)
g in Serv
r1 r2
ce ll ( CI)
S
Back
1 9 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 9 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 9 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 9 67
6 Counters on Electromagnetic Emission (EME) 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 9 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 9 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 9 70
8 B9 Improvements
1 9 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 9 72
9 Dynamic SDCCH Allocation
1 9 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

Min
Max
TCH Capacity Static SDCCH timeslots
1 9 74
Definitions A Static SDCCH timeslot is a physical timeslot fixed allocated on the air interface. It contains 3, 4, 7 or 8 SDCCH sub-channels 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 SDCCH time slots SDCCH time slots Configuration 2
TCH Capacity
TCH Capacity
TCH CAPACITY
Low signaling capacity More TCH capacity
High signaling capacity Less TCH capacity
1 9 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
BCC BCC SDD TCH

Cell
SDC SDC TCH TCH TCH TCH
TCH TCH TCH
TCH TCH TCH
TCH TCH TCH
TCH TCH TCH
TCH TCH TCH
TCH TCH TCH
SDD TCH TCH
1 9 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 9 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
Yes
No
Are they any free SDCCH sub-channel among Static SDCCH timeslots?
Selection of one SDCCH sub-channel
Yes
No
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
SDCCH Request rejected!!!
1 9 78
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 TS with lowest index on TRX with lowest TRX_ID
TCH/SDCCH TS allocated as TCH

TS with LOWEST TCU LOAD TS on FR TRX TS with lowest index on TRX with lowest TRX_ID
1 9 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 9 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 restarted 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 BTS
5 8
BTS
1 7 9
BTS
11 6
12
1 9 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 1 2 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 9 82
Number of Static SDCCH 4 4 8 8 8 8 8 16 16 16 16 16 16 16 24 24 24
Number of Dynamic SDCCH 8 8 16 16 24 24 24 24 24 32 32 32 40 40 40 48 48
Total number of SDCCH 12 12 24 24 32 32 32 40 40 48 48 48 56 56 64 72 72
Maximum SDCCH/TRX ratio 12.0 (note 1) 6.0 12.0 8.0 8.0 6.4 5.3 5.7 5.0 5.3 4.8 4.4 4.7 4.3 4.6 4.8 4.5
Is BCCH/CCCH combined with SDCCH? Yes Yes No No No No No No No No No No No No No No No
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 9 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
n Co
c e n t r i c ce ll
ne
r zon
Oute
r zone
1 9 84
Handover Algorithm Cause 10

CAUSE 10: too low level on the uplink in the inner zone AV_RXLEV_UL_HO < RXLEV_UL_ZONE MS_TXPWR = min (P, MS_TXPWR_MAX_INNER)
and
Averaging window: A_LEV_HO
1 9 85
Handover Algorithm Cause 11

CAUSE 11: too low level on the downlink in the inner zone AV_RXLEV_DL_HO < RXLEV_DL_ZONE BS_TXPWR = BS_TXPWR_MAX_INNER
and
Averaging window: A_LEV_HO
1 9 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
Co
nce
n tric c e
ll
ne
r zon
Oute
r zone
1 9 87
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 + 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)
and and and
1 9 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 9 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
Co
nce
n tric c e
ll
ne
r zon
Oute
1 9 90
r zone

neighbour_RXLEV(0,n)
Inner zone interferer 1
I n ner 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 9 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, EN_CAUSE_13 = ENABLE If INNER zone is more loaded than OUTER, EN_CAUSE_13 = DISABLE If EN_LOAD_BALANCE = DISABLE EN_CAUSE_13 = ENABLE
1 9 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 ner z on e I n ner z on 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
C o n c e n tric c el l
I n ner z on e
Outer zone
Outer zone
1 9 93
Outer zone
The only restrictions are linked to EN_MULTI-BAND_PBGT_HO and EN_BI-BAND_MS parameters.
Incoming Intercell Handovers towards Concentric Cell

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 zo n e
? ?
C el l
C o n c e n tr ic c e l l
1 9 94
Outer zone
Incoming Intercell Handovers towards Concentric Cell [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 The MS is directed towards the INNER zone ELSE The MS is directed towards the OUTER zone
and
1 9 95

1 9 96
End of Module Annexes
1 9 97
Last But One Page

1
@@PRODUCT @@COURSENAME
All Rights Reserved Alcatel-Lucent @@YEAR
All Rights Reserved Alcatel-Lucent @@YEAR @@COURSENAME - Page 1
All rights reserved Alcatel-Lucent @@YEAR Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved Alcatel-Lucent @@YEAR @@COURSENAME - Page 2

3fl10491adaawbzza 02

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

3fl10491adaawbzza 02

Hochgeladen von

Copyright:

Verfügbare Formate

EVOLIUM Base Station Subsystem BSS B10 Introduction to Quality of Service and Traffic Load Monitoring

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

Terms of Use and Legal Notices

All rights reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

4. Topic/Section is Positioned Here

3. Detailed Indicators 3JK11045AAAAWBZZA

4. Handover Indicators 3JK11046AAAAWBZZA 6. Topic/Section is Positioned Here 1. Topic/Section is Positioned Here

2. Topic/Section is Positioned Here 3. Topic/Section is Positioned Here

All Rights Reserved Alcatel-Lucent 2010

Course Outline [cont.]

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

Upon completion of this course, you should be able to:

All Rights Reserved Alcatel-Lucent 2010

Course Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

About this Student Guide

All Rights Reserved Alcatel-Lucent 2010

Where you can get further information

About this Student Guide [cont.]

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

Client (Company, Center) : Language : Switch

Number of trainees : Surname, First name :

Instructional objectives 1 To be able to XXX

Self-assessment of Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2010

Thank you for your answers to this questionnaire

Do not delete this graphic elements in here:

Section 1 GSM QoS Monitoring

All Rights Reserved Alcatel-Lucent 2010

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent 2010

Module Objectives [cont.]

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

Table of Contents [cont.]

All Rights Reserved Alcatel-Lucent 2010

This page is left blank intentionally

1 Monitoring the QoS of the BSS

All Rights Reserved Alcatel-Lucent 2010

1 Monitoring the QoS of the BSS

But also detect, localize, diagnose outages

All Rights Reserved Alcatel-Lucent 2010

1 Monitoring the QoS of the BSS

BSS Optimizers receive good inputs to enhance the network

All Rights Reserved Alcatel-Lucent 2010

2 Monitoring the Traffic Load of the BSS

All Rights Reserved Alcatel-Lucent 2010

2 Monitoring the Traffic Load of the BSS

Analyze traffic characteristics

As input for dimensioning/architecture team

BTS BSC BTS

All Rights Reserved Alcatel-Lucent 2010

3 Information Sources Available

All Rights Reserved Alcatel-Lucent 2010