B10_GSM_QoS and Traffic Load

Section 1 · Module 1 ·

All Rights Reserved © Alcatel-Lucent 20083JK11043AAAAWBZZA Issue 01

Do not delete this graphic elements in here:

All Rights Reserved © Alcatel-Lucent 2008

EVOLIUM Base Station SubsystemIntroduction to Quality of Service and Traffic Load Monitoring - B10

TRAINING MANUAL

3FL10491ADAAZZZZAEdition 01

Copyright © 2007 by Alcatel-Lucent - All rights reservedPassing on and copying of this document, use and

communication of its contents not permitted without written authorization from Alcatel-Lucent




EVOLIUM Base Station Subsystem · Introduction to Quality of Service and Traffic Load Monitoring - B10GSM QoS Monitoring · Introduction1 · 1 · 2

Legal Notice

Switch to notes view!Safety WarningBoth lethal and dangerous voltages are present within the equipment. Do not wear conductive jewelry while

working on the equipment. Always observe all safety precautions and do not work on the equipment alone.

CautionThe equipment used during this course is electrostatic sensitive. Please observe correct anti-static

precautions.

Trade Marks

Alcatel and MainStreet are trademarks of Alcatel.

All other trademarks, service marks and logos (“Marks”) are the property of their respective holders including Alcatel-Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel 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.

CopyrightThis 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-Lucent’s 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 Canadian or other legislation is hereby expressly prohibited.

User obtains no rights in the information or in any product, process, technology or trademark which it includes or describes, and is expressly prohibited from modifying the information or creating derivative works without the express written consent of Alcatel-Lucent.

Alcatel-Lucent, The Alcatel-Lucent logo, MainStreet and Newbridge are registered trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners. Alcatel-Lucent assumes no responsibility for the accuracy of the information presented, which is subject to change without notice.

© 2007 Alcatel-Lucent. All rights reserved.

Disclaimer

In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel 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.

Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment and its operation.





Table of Contents

Switch to notes view!1. GSM QoS Monitoring

1. Introduction

2. Global Indicators

3. Detailed Indicators

4. Handover Indicators

5. Directed Retry Indicators

6. Radio Measurement Statistics Indicators

7. Traffic Indicators

8. Case Studies

9. Annexes





Table of Contents [cont.]

Switch to notes view!

This page is left blank intentionally





Course Objectives


Welcome to Introduction to Quality of Service and Traffic Load Monitoring - B10

After successful completion of this course, you should understand:

Global indicators, in order to assess the general quality of the networkDetailed indicators, in order to detect / identify / locate the main malfunctionsHandover indicators, in order to quantify efficiency and reason of HODirected retry indicators, in order to quantify efficiency of directed retryRMS indicators to ease radio optimization and fault detection Traffic indicators, in order to detect/predict overload and compute adequate cell dimensioning as well as to understand how RTCH resources are used in the network





Course Objectives [cont.]







About this Student Guide

Switch to notes view!Conventions used in this guide

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

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.

WarningAlerts you to instances where non-compliance could result in equipment damage or personal injury.





About this Student Guide [cont.]







Self-Assessment of Objectives

At the end of each section you will be asked to fill this questionnairePlease, return this sheet to the trainer at the end of the training


Instructional objectives Yes (or globally

yes)

No (or globally

no) Comments

Contract number :

Course title :

Client (Company, Center) :

Language : Dates from : to :

Number of trainees : Location :

Surname, First name :

Did you meet the following objectives ?Tick the corresponding box

Please, return this sheet to the trainer at the end of the training





Self-Assessment of Objectives [cont.]


Instructional objectives Yes (or Globally

yes)

No (or globally

no) Comments

Thank you for your answers to this questionnaire

Other comments





Module 1Introduction

3JK11043AAAAWBZZA Issue 01

Section 1GSM QoS Monitoring


3FL10491ADAAZZZZA Issue 01





Blank Page


First editionLast name, first nameYYYY-MM-DD01

RemarksAuthorDateEdition

Document History





Module Objectives

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

Explain what is QoS and Traffic Load monitoring of the BSSExplain what are the information sources available for that purpose





Module Objectives [cont.]






Table of Contents

Switch to notes view! Page

1 Monitoring the QoS of the BSS 72 Monitoring the Traffic Load of the BSS 103 Information Sources Available 124 Introduction to K1205 PC Emulation 28





1 Monitoring the QoS of the BSS






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 outagesdetect (decide according to thresholds)localize (which cell, BSC, etc.)diagnose: radio, BSS, TC problems






Usage

QoS ResultsQoS Results

Management• network monitoring• comparison with competitor• comparison of manufacturers• contractual requirement: licence• quality responsible

Management• network monitoring• comparison with competitor• comparison of manufacturers• contractual requirement: licence• quality responsible

Radio optimization• cell radio quality survey• HO quality monitoring• assessment of tuning efficiency

Radio optimization• cell radio quality survey• HO quality monitoring• assessment of tuning efficiency

BSS maintenance• cell/BSC/TC problem detection

BSS maintenance• cell/BSC/TC problem detection

3 usages of QoS data ⇒ 3 levels of QoS reports:

1. Management team: has to compare Network QoS with competitors' one and to plan Network evolutions.

⇒ needs to have a general view of the Network QoS on a monthly (and sometimes weekly) basis.

2. Radio Optimization team: has to detect bad QoS areas in the network and to implement and assess modifications for QoS improvement.

⇒ needs to have a detailed status and evolution of the QoS at BSS and cell (and sometimes TRX) levels on a weekly, daily (and sometimes hourly) basis.

3. Supervision and Maintenance team: has to detect dramatic QoS degradations and identify the responsible Network Element (and if possible component).

⇒ needs to have the most detailed status of QoS at cell and TRX levels on an hourly basis.





2 Monitoring the Traffic Load of the BSS





2 Monitoring the Traffic Load of the BSS

Definition

Measure the "quantity" of traffic handled by:the networkthe BSCsthe cells

Analyze traffic characteristicscall, handover, location update, etc.

As input for dimensioning/architecture team





3 Information Sources Available






Observation Means

DIFFERENT WAYS TO OBSERVE/MEASURE the GSM network

External Interface AnalysisA interface: MSC/TC-BSCAbis interface: BSC/BTSAir MS/BTS

Counter browser

OMC CountersBSC(NSS)

Tektronix K1205

Gnnettest MPAW&G NPA

QoS data can be built up from different and complementary kinds of information sources.

Usually post-processing applications will build up QoS indicators from:

OMC-R counters provided by the BSS system itself.

Signaling messages provided by a protocol acquisition tool on the different interfaces handled by the BSS: Air, Abis, A (or Ater).






A Interface Trace

INFORMATION SOURCE: EXTERNAL INTERFACE "A"Capture/decode signaling between MSC and BSC-TC (A or Ater MUX)

with "protocol analyzer" (Wandel, Tektronix, Gnnettest, etc.)+ GSM standard, can be used for arbitrage between manufacturers+ Complete information (message contents, time-stamp)+ Possible detection of User/MS/BSS/TC/NSS problems

- High cost of equipment- Time consuming, "post mortem" (installation of tool, file analysis)- Expertise needed for analysis- Low coverage (K1103/MA10: 8 COCs, K1205/MPA: 32 COCs maximum!)

- Large amount of data (>> 10 Mbytes /hour/BSC)

The main advantage of the A interface is to allow the detection of Call Setup failures either due to the User or to the NSS (or PSTN).

Some typical user failure causes are: Some typical NSS failure causes are:

IMSI Unknown in VLR Temporary FailureIMSI Unknown in HLR Resource UnavailableIMEI Not Accepted Switching Equipment CongestionPLMN Not Allowed Normal UnspecifiedService Option Not Supported Recovery on Timer ExpiryRequested Service Not Supported Call Reject Unassigned Number InterworkingOperator Determined Barring Protocol ErrorUser Alerting Network FailureFacility Not Subscribed CongestionNo Route to DestinationNormal Call ClearingUser BusyInvalid Number FormatCall RejectInterworkingNormal Unspecified

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.






Example of Trace

On a K1205 protocol analyzer






Abis Interface Trace

INFORMATION SOURCE: EXTERNAL INTERFACE "Abis"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

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

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 DownLink and UpLink paths can be observed and compared.

BUT from B7 release, the Radio Measurement Statistics (RMS) feature implemented in the BSS provides a good level of information allowing to reduce the number of Abis traces to be done for radio network optimization.






Air Interface Trace

INFORMATION SOURCE: EXTERNAL INTERFACE "Air"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

- High cost of equipment- Very time-consuming- Difficulty to perform a lot of calls

-> number of samples insufficient -> only a few streets

- No uplink

The main advantage of the Air trace is to associate a radio quality measurement to a given geographical area of the network.

Even if the RMS feature will allow to assess the radio quality as perceived by the end user, no location of the radio problems is provided through the RMS.






Performance Measurement Counters

SUB-SYSTEM COUNTERSCount events seen by sub-system, value reported periodically (1 hour)

+ 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

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 chartIn which sub-system are the BSS QoS indicators computed and stored?

BSC

BSC

BSC

OMC-R

OMC-R OMC-R

NPA

RNO






BSS Counters

Combined into significant formulae: indicatorsUsed to monitor BSS network qualityOver a complete network, with breakdown per cell/BSC

SPECIFIC DRAWBACKNSS/PSTN/MS/USER problems not seen

As BSS PM counters are defined in order to provide information to assess the QoS of the BSS and help to detect BSS misbehavior, there is no way to identify QoS problems due to NSS, PSTN or User.






NSS Counters

Combined into significant formulas: indicatorsUsed to monitor NSS network qualityOver a complete network, with breakdown per BSC (maximum)

SPECIFIC DRAWBACKSBSS problems usually not precisely identifiedNo breakdown per cell

The NSS QoS is provided through NSS PM counters and indicators. It is out of the scope ot this training course.






Alcatel-Lucent BSS Counters

INFORMATION SOURCES: BSS Counters (1/2)Performance Management implementation

Easy and cost-effective way to monitor network and carried trafficPrinciple:

For a given duration (granularity period= typically 1 hour)To count pre-defined events occurring on the Abis or A interface, or internally. Counters stored with breakdown per network component (i.e. cell)

In the BSS B9, around 1000 counters are available (without GPRS).

Alcatel-Lucent has chosen to implement PM counters in the BSC and to increment them mostly on Abisinterface 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).






Alcatel-Lucent BSS Counters [cont.]

INFORMATION SOURCES: BSS Counters (2/2)In Alcatel-Lucent BSS (except GPRS), counters are computed by the BSC, based mainly on Abis messages.Every reporting period, counters values are sent to the OMC-R for storage.Several counters are reported to the OMC-R permanently every PM granularity period:

Type 180: per cell adjacency Type 110 per cellOther Types: per TRX / N7 Link / BSC …/…

Millions of counters are collected every day






BSS Counter Example

MC718: counter number

NB_TCH_NOR_ASS_SUCC_TRX: counter nameCumulative: method of computationType 110: BSS PM measurement type to which the counter belongs Measured object: minimum object level for which the counter is provided: TRX or CELL or BSC or N7 LINK or X25 LINK etc.

All counters are described in PM Counters and Indicators.






BSS Counter Characteristics

Collection mechanism

CumulativeThe 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.

InspectionEvery 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.

ObservationSet of recorded information about a telecom procedure (handover, channel release, UL & DL measurements reporting).

Main counters are of cumulative type.

Inspection counters are of gauge type.

Observation counters are grouped in a Performance Measurement record associated to a particular GSM BSS telecom procedure: SDCCH channel seizure, TCH channel seizure, internal handover, etc.






BSS Performance Measurement TypesB10

N° Type Name Type definition1 Traffic Measurement Set of counters related to the traffic evaluation per telecom procedure2 Resource Availability Measurement Set of counters related to the availability of the CCCH, SDCCH, or TCH channels3 CCCH channel resource usage measurements Set of counters related to the usage of CCCH channel (PCH, AGCH, RACH)4 SDCCH channel resource usage measurements Set of counters related to the usage of SDCCH channel5 TCH channel resource usage measurements Set of counters related to the usage of TCH channel6 TCH Handover Measurements Set of counters related to the TCH handover procedure7 LAPD Measurement Set of counters related to the LapD logical links8 X.25 Measurement Set of counters related to the X25 links OMC-BSC9 N7 Measurement Set of counters related to the N7 Signaling Links

10 SDCCH Observations Observation counters on SDCCH channels allocated11 TCH measurements observations Observation counters on 08.58 MEASUREMENT REPORT for a TCH12 Internal Handover Observations Observation counters on internal intra-cell or inter-cell SDCCH or TCH handover13 Incoming External Handover Observations Observation counters on incoming external SDCCH or TCH handover14 Outgoing External Handover Observations Observation counters on outgoing external SDCCH or TCH handover15 TCH Observation Observation counters on TCH channel allocated18 A Interface measurements different causes of 08.08 CLEAR REQUEST and 08.08 ASSIGNMENT FAILURE19 SMS PP Measurements Set of counters related to Short Message Service Point to Point25 SCCP Measurements Set of counters related to SCCP Layer of the N7 signaling Links26 TCH outgoing Handover per adjency Set of counters related to outgoing TCH handover provided per adjency27 TCH incoming Handover per adjency Set of counters related to incoming TCH handover provided per adjency28 SDCCH Handover Set of counter related to the SDCCH handover procedure29 Directed Retry measurements Set of counter related to the directed retry handover procedure30 SMS CB Measurements Set of counters related to Short Message Service Cell Broadcast31 Radio Measurement Statistics Set of counters providing radio quality measurements for TRX/Cell32 Change of frequency band measurements Set of counters related to handovers including a change of TCH Frequency band33 BTS Power Measurement Average emitted power at the BTS antenna output

110 Overview measurements Set of key counters allowing to access Quality of Service of a given Cell/BSC/Network180 Traffic Flow measurements Set of counters related to incoming inter-cell SDCCH/TCH handover performed per adjencyANNEX 6

Modified B10

BSS Performance Measurement types (PM types) are split into two categories:

standard types (7, 8, 9, 18, 19, 25, 28, 29, 30, 31, 32,110, 180)

detailed types (1, 2, 3, 4, 5, 6, 10, 11, 12, 13, 14, 15, 26, 27)

The most important types for QoS monitoring and Radio Network Optimization are in bold.

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)






Exercise

Observation Means: find the best source of information.Observation to be done : Best source Why

6- history of network quality for several weeks

8- discriminate problems between BSS/NSS. BSS and NSS coming from different providers9- In a building, one is thinking that an elevator is inducing PCM trouble, how to confirm ?10- Identify potential interfering cells of 1 Cells

5- localise abnormal cells in a network

7- compare networks quality

3- get average network quality

4- localise precise location of a radio pb

1- overall radio quality of 1 cell Counters Type 31: RMS

2- monitor user failures





4 Introduction to K1205 PC Emulation






Usage

The trace done with K1205 can be read: Directly on K1205 itselfOn 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






Measurement Scenarios Screen

To select binary trace file

To select binary trace file

To enter in monitoring mode to

analyze the A trace

To enter in monitoring mode to

analyze the A trace

To filter the main GSM protocols and

messages

To filter the main GSM protocols and

messages

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 Filterand select:

SCCP Except UDTKeep all DTAP BSSM Except PAGIN

Select also all Logical Links

ANNEX 4

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 View1 line / message

Short View1 line / message

Frame ViewFull decoding of

selected message

Frame ViewFull decoding of

selected message

Packet viewMessage content in hexadecimal

Packet viewMessage content in hexadecimal

To extract 1 callTo extract 1 call






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 ReferenceLR: Destination Location Reference

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

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.REC1) 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?





Self-assessment on the Objectives

Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this moduleThe form can be found in the first partof this course documentation





End of ModuleIntroduction





Module 2Global Indicators3JK11044AAAAWBZZA Issue 01








Blank Page




Document History





Module Objectives


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





Table of Contents


1 Indicators Definition 72 Methodological Precautions 133 Typical Call Failures 204 Description of Global Indicators 835 Traps and Restrictions of Global Indicators 1046 Global Indicators Interpretation 111





1 Indicators Definition






BSS Indicators Definition (Alcatel-Lucent)

Global / Detailed

Numerical data providing information about network performance regarding: The complete network: GLOBAL indicatorAn element of the network: DETAILED indicator

TS/TRX/CELL/BTS/BSC/TC

A formulae of several countersCounters vs. Indicators

Counters: provided by the BSS equipmentIndicators: computed by BSS Monitoring equipment

The indicators computation can be performed from several counters or by a simple counter mapping.

Example:

call drop rate = Call Drop nb / Call nb = f(counters)

call drop = Call drop nb = 1 counter






Global Indicators

Measure the performance of the complete network

Analyzed according to their trend and valuesUsually every day (week, month)

Compared with:Competitor results if availableContractual requirementsInternal quality requirements






Thresholds

EXAMPLE: Thresholds on Call Drop Rate indicator

Weekly CDR "GSM"

0,00%

0,50%

1,00%

1,50%

2,00%

2,50%

3,00%

3,50%

1 5 9 13 17 21 25 29 33 37 41 45week number

CD

R

weekly call drop ratecontractual call drop ratequality CDR

Weekly CDR "GSM"

0,00%

0,50%

1,00%

1,50%

2,00%

2,50%

3,00%

3,50%

1 5 9 13 17 21 25 29 33 37 41 45week number

CD

R

weekly call drop ratecontractual call drop ratequality CDR

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.






Exercise

Are the indicators in the table below global ones?

INDICATOR DESCRIPTION G ?

average of call setup success rate for the network Yesrate of call lost due to radio pb on cell CI=14, LAC=234 Nocall drop rate in your capitalcall drop rate of the cell covering a specific buidling% of HO with the cause better cell (among other causes) for the networkaverage rate of TCH dropped for all TRX of the network carrying 1 SDCCH8 rate of SDCCH dropped on TRX1 of cell 12,24call success of 1 PLMN% of cells being congested today

INDICATOR DESCRIPTION G ?

average of call setup success rate for the network Yesrate of call lost due to radio pb on cell CI=14, LAC=234 Nocall drop rate in your capitalcall drop rate of the cell covering a specific buidling% of HO with the cause better cell (among other causes) for the networkaverage rate of TCH dropped for all TRX of the network carrying 1 SDCCH8 rate of SDCCH dropped on TRX1 of cell 12,24call success of 1 PLMN% of cells being congested today






Typical KPI of Radio Network

Example of KPI used on network:

KPI Parameter Source Call Drop Rate OMC/Drive test

Congestion Rate OMC/Drive test

Handover Success Rate OMC/Drive test

Busy Hour Traffic OMC

TCH Utilization OMC

Call Setup success rate OMC/Drive test

Coverage Drive test

Quality Drive test

The KPI is a good way to measure the overall performance of the network. Several KPI parameters will be defined in the network to enable the operator to monitor the network performance throughout important events, new release, soft/hardware upgrades, etc.

Normally the formula of KPI are defined by the operator, and usually different operators may consider different KPIs and use different formulas. The KPI can be derived from driving tests and OMC traffic statistics.





2 Methodological Precautions






Objective

Avoid typical errors regarding indicators interpretation






Global Indicator Value

A good value for a global indicator⇓

All network components are OK regarding this indicator

Example:A global call drop rate of 1% can hide some cells with 10% of call drop rate






Network Element Aggregation

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

number of calls number of call drop call drop ratecell 1 390 8 2,10%cell 2 546 29 5,25%cell 3 637 20 3,10%cell 4 1029 12 1,14%cell 5 536 3 0,50%cell 6 2 1 50,00%cell 7 3 1 33,00%cell 8 210 4 2,11%cell 9 432 5 1,20%cell 10 321 4 1,11%

average of cell results 9,95%total nb of drop/total number of calls 2,10%






Global Indicator Validity

To be reliable, an indicator must be based on a sufficient number of events

Estimation theory (MR.Spiegel, « theory and problems of probability and statistics », SCHAUM):

if « p » is the probability of success for a complete populationif 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% ]This law cannot be used directly for indicators (an hourly indicator is not based on a random sample), but it is giving a rough estimate of level of confidence one can apply regarding the size of the sample

If a sample (number of calls) is too small, one can take it for a longer duration

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

Take care of data consolidation

Example: Mean cell congestion rate during 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? (definition of busy hour?)

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 Sample

(calls)conclusion OK ?

call drop = 0.9% in your country 2456435 all the cells have a good call drop NOK

call setup success for cell 15, 145 = 99.5% 2315 there is a good call setup success rate for15, 145

In Paris: 2500 cells with 95% of call setupsuccessIn the rest of France: 5000 cells with98%

3267872for France

In France, call setup success = 97 %

call drop for BSS « BSS_1 » = 1% 4500 the call drop for BSS_1 is good

call drop for cell 156;13 = 5% 215 cell 156;13 has certainly a trouble

for BSS 1, call drop of 2.0%for BSS 2, call drop of 3.0%

40002000

LA = BSS1 + BSS2 has a call drop of 2.3 %

MSC « Stadium » has a call setup success of95 %

15346 BSS1 belonging to MSC Stadium has a call setupsuccess of 95%





3 Typical Call Failures






Objective

Description of the main call success and failures cases, with:Main specific countersMain protocol timers

Diagnose the main case of failures on A interface traces using the K1205 emulation software






Call Setup phasing

4 stages for a call establishment, 2 for a location update:1- Radio link establishment2- "SDCCH phase“

then only for "Circuit Switch call"3- TCH assignment4- "Alerting/connection" phase

Each phase has a specific utility and some weaknesses

Radio Link EstablishmentSDCCH PhaseTCH assignmentAlerting/CNX Phase





MS BTS BSC MSC

CHANNEL REQUEST-------------(RACH)------------> CHANNEL REQUIRED

----------------------------------------------> MC8CCHANNEL ACTIVATION (SDCCH)

<---------------------------------------------- MC148CHANNEL ACTIVATION ACK

---------------------------------------------->IMMEDIATE ASSIGN COMMAND

IMMEDIATE ASSIGN <---------------------------------------------- start T3101MC8B

<------------(AGCH)-------------SABM (L3 info)

-------------(SDCCH)-----------> ESTABLISH IND (L3 info)UA (L3 info) ----------------------------------------------> stop T3101

<-----------(SDCCH)------------- MC02CR (COMPLETE L3 INFO)---------------------------------->

CC<----------------------------------

MSC


Radio Link Establishment - OC success

Originated Call: RLE success case

T3101: guard timer for SDCCH allocation (Default: 3 seconds)CR/CC are used to exchange SCCP references

Any further message related to this call will have one (or 2) of these 2 referencesK1205 can extract the call using these references (SLR, DLR!!)

Specific case of Call establishmentfailure:Loss of messages due to LapD congestioncan be followed with a counter (see notes)LapD


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.

MC8C counts the number of Channels Required received from the MS in a cell.

MC148 counts the number of SDCCH channels activated (therefore allocated) in a cell.

MC8B counts the number of times an MS is commanded to access an SDCCH channel in a cell.

MC02 counts the number of MSs which have successfully accessed an SDCCH in a cell as part of a Mobile Originating (MO) call.

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.

Take care that, when the BSC is congested on the downlink, some messages are discarded. This may result for example in call establishment failures, loss of paging messages or delay in handover procedures.

A LapD counter that indicates the time a LapD link is congested is created to analyze the cause of a degradedquality of service. This counter is implemented in type 7 and thus be only available in a detailed measurement campaign.

Counter: L1.18: TIME_LAPD_CONG

Definition: Time in seconds during which the LapD link is congested in transmission in the BSC.

BinhPT

Typewriter

Main counter- real code

Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2008 For Evaluation Only.

BinhPT

Typewriter

If TA > TA-filter: Reject call ( TA, TA-Filter = 63 bits) Max coverage: 35- 40 km

BinhPT

Typewriter

1 bit TA ~ 550m ( 0.557ms sen 156.25 bits ) 1 bits ~ 0,004ms x 300.000.00 ~ 534.7m

BinhPT

HighLight

BinhPT

HighLight






Radio Link Establishment - TC Success

Terminated Call: RLE success caseMS BTS BSC MSC

PAGINGPAGING COMMAND <----------------------------------

PAGING REQUEST <---------------------------------------------- start T3113<------------- (PCH) -------------- MC8A

CHANNEL REQUEST-------------(RACH) ------------> CHANNEL REQUIRED




IMMEDIATE ASSIGN <---------------------------------------------- Start T3101<------------ (AGCH) ------------- MC8B

SABM (PAGING RESP)-------------(SDCCH) -----------> ESTABLISH IND (PAGING RESP)

UA (PAGING RESP) ----------------------------------------------> Stop T3101<----------- (SDCCH) ------------- MC01

CR (COMPLETE L3 INFO)---------------------------------->

stop T3113CC

<----------------------------------


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.

Caution:

A paging Request message sent on the Air interface by the BTS may contain several MS identities. 3 Paging Request types can be used:

in Paging Request Type 1: up to 2 MSs (IMSI1,IMSI2) can be included.

in Paging Request Type 2: up to 3 MSs (IMSI1,TMSI1,TMSI2) can be included.

in Paging Request Type 3: up to 4 MSs (TMSI1,TMSI2,TMSI3,TMSI4) can be included.

On the other hand, a Paging message and a Paging Command message relate to only one MS identity.

BinhPT

Typewriter

Paging: Ask MS auto connect to network by itself Only 6 counter in process of making and terminating

BinhPT

HighLight






Radio Link Establishment - MO Success for DTM

Terminated Call: RLE success case


MS BTS BSC MSC

CHANNEL REQUEST-------------(RACH) ------------> CHANNEL REQUIRED




IMMEDIATE ASSIGN <---------------------------------------------- Start T3101<------------ (AGCH) ------------- MC8B

-------------(SDCCH) -----------> ESTABLISH IND (L3 info)UA (L3 info) ---------------------------------------------->

<----------- (SDCCH) -------------

MFS

Packet Idle Mode

SABM[L3 info]

<----------------------------------------------

Mult. SACCH info Modify [SI5, SI6]

COMMON ID

BSC Shared DTM Info Indication

SCCP Connection Req (Compt. L3 info)

SCCP Connection ConfirmClassmark Change DI (Classmark Change)

Creation of DTM MS context Class Mark update

B10

New B10






Radio Link Establishment - Paging

RLE > Paging: MC8A=C8A

Normally all cells of the same Location Area must have the same MC8A counter value since all these cells must be paged for an MT call on an MS located in the Location Area they are included in.

If not: it means that a cell is not declared in the right LA at NSS level.






Radio Link Establishment - RACH Counter

RLE > RACH: MC8C=C8C

Caution: All Channels Required (therefore RACH) are counted in MC8C: valid and invalid causes (see later). Indeed ghost RACHs are also counted.

The Channel Required content corresponds to the Channel Request message sent by the MS to the BTS.

This Channel Request message is made up of one byte with 2 Information Elements (IEs):8 7 6 5 4 3 2 1

+-----------------------------------------------+│ ESTABLISHMENT │ RANDOM │

│ + - - - - - - - - + ││ CAUSE │ REFERENCE │+-----------------------------------------------+

ESTABLISHMENT CAUSE: This information field indicates the reason for requesting the establishment of a connection. This field has a variable length (from 3 bits up to 6 bits).

RANDOM REFERENCE: This is an unformatted field with a variable length (from 5 bits down to 2 bits).

Due to the fact that the NECI bit is always set to 1 in Alcatel-Lucent BSS, Establishment causes can be divided into 2 categories:

Valid causes: 5 (6 if GPRS)000: Location Update (Normal, Periodic, IMSI Attach)100: Terminating call101: Emergency call 110: Call Re-establishment111: Originating call (not emergency)011: if GPRS is implemented in the cell

Invalid causes: 3 (2 if GPRS)001: 010: 011: if GPRS is not implemented in the cell





3 Typical Call Ffailures

Radio Link Establishment - OC Success Counters Split

RLE > success MO split: MC02x=C02x

MC02 =MC02A+MC02B+MC02C+…….+MC02G+MC02H+MC02i

MC02A: LU

MC02B: SMS

MC02C: SS

MC02D: LU follow-on

MC02E: CR

MC02F: unknown

MC02G: IMSI Detach

MC02H: EC or NC

MC02i: LCS

MC02A = Number of SDCCHs successfully seized for Normal or Periodic LU request (IMSI Attach also counted).

MC02B = Number of SDCCHs successfully seized for Short Message Service.

MC02C = Number of SDCCHs successfully seized for Supplementary Service.

MC02D = Number of SDCCHs successfully seized for LU with follow-on bit set to 1 (means that the SDCCH phase will be followed by a TCH assignment for speech call establishment).

MC02E = Number of SDCCHs successfully seized for Call Re-establishment.

MC02F = Number of SDCCHs successfully seized in case of L3 Info (within 08.58 ESTABLISH INDICATION) unknown by the BSC but transferred to the MSC.

MC02G = Number of SDCCHs successfully seized for IMSI Detach.

MC02H = Number of SDCCHs successfully seized for Normal or Emergency call.

MC02i = Number of Mobile Originating SDCCH establishments for LCS purposes.

Also, Evaluation of the Mobiles location (see the next slides)

LCS: Location Services

BinhPT

HighLight

BinhPT

HighLight

BinhPT

HighLight

BinhPT

HighLight

BinhPT

HighLight

BinhPT

HighLight

BinhPT

HighLight

BinhPT

HighLight

BinhPT

HighLight

BinhPT

Typewriter

Emergency call Normal call

BinhPT

Typewriter

Location Update

BinhPT

Typewriter

Call reconnect






Radio Link Establishment - SDCCH Congestion Failure

Main failure cases for Radio Link Establishment Radio Link EstablishmentSDCCH PhaseTCH assignmentAlerting/CNX Phase

SDCCH Access Failure

SDCCH CongestionSDCCH

Congestion

SDCCH Radio Failure

SDCCH Radio Failure

SDCCH BSS Problem

SDCCH BSS Problem






Radio Link Establishment - SDCCH Congestion

RLE > SDCCH congestion

The Immediate Assignment Reject mechanism can be disabled at OMC-R level

It is not activated for answer to paging If disabled, no answer to the MS

The MS will repeat automatically its request in case of congestion (next slides)

Waiting for T3122 expiry in case of Immediate Assignment RejectWaiting for T3120 expiry otherwise


MS BTS BSCMSC

CHANNEL REQUEST-------------(RACH)------------> CHANNEL REQUIRED

----------------------------------------------> MC8CNo free SDCCH !!MC04

IMMEDIATE ASSIGN COMMAND<----------------------------------------------

IMM. ASS. REJECT (immediate assignment reject) MC8D, and MC8B<-------------(AGCH)------------

MSC

In case of Immediate Assignment Reject: T3122 = value of Wait_Indication parameter sent by the BSC to the MS.

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

250 and 250+T-1 for a phase 1 MS where: T=Tx_integer parameter (1 value per cell chosen between 3 to 50 slots)

S and T+S for a phase 2 MS where: T=Tx_integer parameter (1 value per cell chosen between 3 to 50 slots)S is a parameter depending on the CCCH configuration and on the value of Tx_integer as defined in the following table:

TX_integer S(CCCH Not Comb) S(CCCH Combined)

3, 8, 14, 50 55 41

4, 9, 16 76 52

5, 10, 20 109 58

6, 11, 25 163 86

7, 12, 32 217 115

BinhPT

Typewriter

: MS random timer between 02 request

BinhPT

Typewriter

BSC assigned timer between 02 request of the MS

BinhPT

Line

BinhPT

Line

BinhPT

Line

BinhPT

Typewriter

T3120

BinhPT

Typewriter

Max period 249 TS = 0.139s (217 + 32)

BinhPT

Typewriter

Time line

BinhPT

Typewriter

1st REQ

BinhPT

Typewriter

2nd REQ

BinhPT

Typewriter

Congestion - means SDCCH use for traffic ( Average SDCCH duration = 5s )

BinhPT

Line

BinhPT

Line

BinhPT

Line

BinhPT

Line

BinhPT

Typewriter

1st REQ

BinhPT

Typewriter

2nd REQ

BinhPT

Typewriter

BSC send IM REJ Wait Indication ( 0-255s) Follow the IM REJ

BinhPT

Typewriter

Start T3120

BinhPT

Typewriter

End T3120 Stet T3122 = Wait Indication

BinhPT

Typewriter

Long timer - T3122

BinhPT

Typewriter

MS

BinhPT

Typewriter

Time line

BinhPT

Typewriter

WI_OP use for SDCCH service like SMS, LU ( use for location update ) WI_OC: orginating call WI_CR: call reconnect WI_EC: emergency call

BinhPT

Typewriter

If MS run LU, then T3122 = WI_OP

BinhPT

Typewriter

: Congestion counter

BinhPT

Typewriter

IM REJ counter






Radio Link Establishment - SDCCH Congestion Counter

RLE > SDCCH congestion: MC04=C04






Radio Link Establishment - SDCCH Cong. Consequences

RLE > SDCCH congestion: MAIN CONSEQUENCES

The MS will try "max_retrans +1 " times before giving upImmediately for phase 1 MSAfter T3126 for phase 2 MS (still waiting for Immediate Assignment during this timer)

In case of "max_retrans+1" failures, the MS will:Either try an automatic cell reselectionOr do nothing

In case of LU, the MS will attempt a new LU requestIn case of Call establishment, the MS will not re-attempt automatically. It is up to the subscriber to try to set up the call again


BinhPT

Typewriter

Define in MS

BinhPT

HighLight

BinhPT

Typewriter

SDCCH Cong rate ( 5% ) = MC04/MC08C 1. Find bad cell ( check with thresold)

BinhPT

Typewriter

Cell1 Cell 2 Cell 3 Cell 4 2% 6% 20% 7%

BinhPT

Typewriter

SDCCH CR

BinhPT

Typewriter

2. Analysis related counter for causes MC02A MC02B MC02D MC02H Main Causes Solution Cell 2 0 21 0 120 Call Add SDC or TCH Cell 3 12 430 0 11 SMS Add SDD Cell 4 245 21 5 5 LU

BinhPT

Typewriter

A train with 1000 MS pass LA border LU happen when MS reselect the new LA cell Rule for select New LA cell RxLev ( new LA ) > RxLev (serving) + CRH Increase CRH - reduce reselect cell Periodical LU - T3212 ( Normal: 30 x 6 minutes ) Increase WI_OP Add more SDCCH ( 01 BCC with 88 SDCCH channel ( 11 SDCCH/TS) ; 01 BCC + CCH with 176 SDCCH ) Option 1: TCH high traffic - add SDC ( Static) or add TRX Option 2: TCH free - add SDD

BinhPT

Rectangle

BinhPT

Rectangle

BinhPT

Rectangle

BinhPT

Rectangle

BinhPT

Square

BinhPT

Rectangle

BinhPT

Rectangle

BinhPT

Typewriter

01 TS - 8 SDCCH Channel

BinhPT

Line

BinhPT

Line

BinhPT

Line

BinhPT

Typewriter

Static: SDC

BinhPT

Typewriter

Dynamic: SDO ( SDCCH/TCH)

BinhPT

Rectangle

BinhPT

Typewriter

BCC = BCCH + CCCH BCCH - TS0 CCH = CCCH BCCH - TS2






Radio Link Establishment - SDCCH Cong. Causes/Solutions

RLE > SDCCH congestion: MAIN causes/solutions

Location area border results in excessive location update and SDCCH attempt

Inadequate LA design (too many LUs)Modify CRH (Cell Reselect Hysteresis)Modify BSC period location updateSolve frequent handover problem between dual-band network

Excessive short messagesAdd SDCCH channelEnable dynamic SDCCH Dynamic Allocation function

Insufficient system capacity, lack of SDCCH channelsExpansion for more TCH and SDCCH channelsMore SDCCHs should be added

Improper configuration of system parameters, RACH system parameterIncrease RACH access threshold (overcoming interference) with care!


SDCCH congestion can be too high because of the subscribers' traffic demand in terms of calls / LUs.

Solution = add a TRX or site / redesign the LA plan

High SDCCH congestion can be observed at peculiar period of the day due to a peak of LU requests generated by a big group of subscribers entering a new LA at the same time (bus, train, plane).

Solution = redesign the LA plan or play on radio parameters (CELL_RESELECT_HYSTERESIS, WI_OP)

High SDCCH congestion can be abnormally observed without real MS traffic in case a high level of noise or the proximity of a non-GSM radio transmitter.

Solution = change the BCCH frequency or put an RX filter

High SDCCH congestion can also be abnormally observed in a cell in case one of its neighboring cell is barred.

Solution = Remove the barring

BinhPT

Typewriter

( Too many MS access )






Radio Link Establishment - SDCCH Cong. Causes/Solutions [cont.]

RLE > SDCCH congestion: MAIN causes/solutions

Board (TRX) fault and transmission fault result in SDCCH congestion

"Common Transport Effect"Difficult to avoid for small cells

Abnormal SDCCH traffic”Phantom" channel requests (seen in SDCCH RF failure session)Neighboring cell barred


SDCCH congestion can be too high because of the subscribers' traffic demand in terms of calls / LUs.

Solution = add a TRX or site / redesign the LA plan

High SDCCH congestion can be observed at peculiar period of the day due to a peak of LU requests generated by a big group of subscribers entering a new LA at the same time (bus, train, plane).

Solution = redesign the LA plan or play on radio parameters (CELL_RESELECT_HYSTERESIS, WI_OP)

High SDCCH congestion can be abnormally observed without real MS traffic in case a high level of noise or the proximity of a non-GSM radio transmitter.

Solution = change the BCCH frequency or put an RX filter

High SDCCH congestion can also be abnormally observed in a cell in case one of its neighboring cell is barred.

Solution = Remove the barring






Radio Link Establishment - SDCCH Cong. Resolution?

RLE > SDCCH congestionDYNAMIC SDCCH ALLOCATION

CHANNEL REQUESTCHANNEL REQUIRED

MS BTS BSC

(RACH)

If No free SDCCH, thenrun dynamic SDCCH/8 timeslot allocation

algorithm. If allocation is successful, then

activate dynamic SDCCH sub-channeland serve request

If allocation was unsuccessful, then reject SDCCH request (possiblyusing the Immediate Assignment Reject procedure).

MC801a&b

MC802a&b


SPECIFIC COUNTERS (Type 110 / Cell Level):

MC800 Average number of available dynamic SDCCH/8 timeslots.

MC801a Average number of busy dynamic SDCCH/8 timeslots allocated as TCH (FR or HR).

MC801b Maximum number of busy dynamic SDCCH/8 timeslots allocated as TCH (FR or HR).

MC802a Average number of busy SDCCH sub-channels allocated on the dynamic SDCCH/8 timeslots.

MC802b Maximum number of busy SDCCH sub-channels allocated on the dynamic SDCCH/8 timeslots.These four previous 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 / SDCCHsare 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.






Radio Link Establishment - SDCCH Radio Failure

Main failure cases for Radio Link Establishment



Congestion

SDCCH Radio Failure

SDCCH Radio Failure

SDCCH BSS Problem

SDCCH BSS Problem







Radio Link Establishment - SDCCH Radio Access Failure

RLE > SDCCH RF Failure

MS BTS BSC MSCCHANNEL REQUEST

-------------(RACH)------------> CHANNEL REQUIRED----------------------------------------------> MC8C

CHANNEL ACTIVATION (SDCCH)<---------------------------------------------- MC148

CHANNEL ACTIVATION ACK---------------------------------------------->IMMEDIATE ASSIGN COMMAND

IMMEDIATE ASSIGN <---------------------------------------------- start T3101<------------(AGCH)------------- MC8B

IMMEDIATE ASSIGN-------(SDCCH)-----X

T3101expiry->“radio failure”MC149


MC149 counts the number of SDCCH access failures due to radio problems.

BinhPT

Typewriter

Failure due to timer expire

BinhPT

Typewriter

SDCCH Fail Rate = MC149/MC8B ( 3% ) 1. Check Thresold, find bad cell 2. Check with TCH Failure rate SDC Fail TCH Fail Cell1 8% 4% Real radio Fault Cell2 35% 1% System fault

BinhPT

Line

BinhPT

Line

BinhPT

Typewriter

3. Detect system fault Case 1 : Process freezing ( sleeping cell ) Reset TCU (manage the cell), restart TRE/BTS, delete/create cell Case 2: LapD Congestion Active TYPE7 - Check counter: L1.18: TIME_LAPD_CONG/3600 - 5% LapD is RSL Normal load - 4 RSL --> 1 PCM TS High load - 2 RSL --> 1 PCM TS

BinhPT

Typewriter

Conf 2:

BinhPT

Typewriter

Conf 1:

BinhPT

Typewriter

Case 3: CCCH Congestion ( If > 88 SDCCH, must use CCH ) For < 88SDCCH, High SDCCH fail, check counter ASSIGN REJ rate - MC925f / MC925(e+f) ; Pag REJ rate - MC925h/MC925(g+h) If Assign REJ rate > 5%, or Pag REJ rate > 10% or both bad, then need add CCH






Radio Link Establishment - Real Radio Problems


Main causes > real radio problems

Unbalanced cell power budgetBad coverage (for example a moving car)Interference (for example downlink)

In case of radio failure, the MS will retry as for SDCCH congestion


Unbalanced Power Budget:

Bad coverage:

Interference:

DL interference area

AGCH lost

RACH

building

BTS

Channel Request

Access Grant

Max Path Loss ULMax Path Loss DL

AGCH

RACH






Radio Link Establishment - Ghost RACH


Main causes > "Phantom/Ghost/Spurious/Dummy ... RACH"

Channel request received but not sent: 3 causesNoise decodingReception of channel request sent to a neighboring cellReception of HO_ACCESS sent to a neighboring cell






Radio Link Establishment - Ghost RACH Causes

RLE > SDCCH RF FailureMain causes > "Phantom/Ghost/Spurious/Dummy ... RACH"Example of a channel required message

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.






Radio Link Establishment - Ghost RACH Causes [cont.]

RLE > SDCCH RF FailureMain causes > "Phantom RACH" > noise decodingGSM 05.05: " 0.02 % of Rach Frame can be decoded without error without real input signal" (No impact for the system)

BCCH not combined: 51 Rach/Multi Frame > (3600 * 1000) ms / 4.615 ms at 0.02 %: 156 dummy RACH/hourBCCH combined: 27/51 RACH/Multi-Frame > 83 dummy RACH/hour3/8 of causes (field of channel request, 5 valid causes over 8) will be unvalidExample of induced SDCCH traffic:

(5/8*156*T3101 (3 sec))/3600 = 0.08 Erlang SDCCH

Some tips: Dummy Rach load depends on minimum level for decoding configured in Evolium™ BTSDuring period with low real traffic (night), high rate of dummy RACHFor dummy RACH, the channel required has a random value of TA

STRUCTURE of the MULTIFRAME in "TIME SLOT" 0

-

R = RACH

DOWNLINKf s b b b b C C C C

31 51 1211 2 3 4 5 6 7 8 9 10 20 41f s f s f s f sC C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C -

(Multiframes of 51 frames)

f = FCCH s = SCH b = BCCH

f s

C C C C = CCCH (PCH or AGCH)

UPLINKR R R RR R R R R R R RR R R R R R R RR R R R R R R RR R R R R R R RR R R RR R R RR R R R R R

(Non-combined BCCH)

(Combined BCCH)

R = RACH

DOWNLINK

F = FCCH S = SCH B = BCCH C = CCCH (PCH or AGCH)

UPLINK

F S B C F S F S F S -F SC C D0 D1 D2 D3 A0 A1

F S B C F S F S F S -F SC C D0 D1 D2 D3 A2 A3

R R R RR R R R R R R RR R R R R R RR R R R R RR RD3 A2 A3 D0 D1 D2

R R R RR R R R R R R RR R R R R R RR R R R R RR RD3 A0 A1 D0 D1 D2

Dn/An = SDCCH/SACCH/4

51 multiframe duration = 51 x 8 x 0,577 = 235ms







RLE > SDCCH RF FailureMain causes > "Phantom RACH" >noise decoding

No subscriber -> no impact for subscriberBut MC149 incremented -> SDCCH RF access failure is impacted

MS BTS BSC MSC

CHANNEL REQUIRED----------------------------------------------> MC8C

CHANNEL ACTIVATION (SDCCH)



IMMEDIATE ASSIGN <---------------------------------------------- start T3101<------------ (AGCH) ------------- MC8B

T3101expiry->“radio failureMC149







RLE > SDCCH RF FailureMain causes > "Phantom RACH" > Channel Request

sent to the neighboring cell

Subscriber not impacted (real transaction performed elsewhere) But MC149 incremented -> SDCCH RF access failure is impacted Usual radio planning rules are sufficient to avoid the trouble

2 cells must not have the same (BCCH, BSIC) couple

M S B TS B SC M SC

C H AN N EL R EQ U IR ED----------------------------------------------> M C 8C

C H AN N EL AC T IVAT IO N (SDCCH)<---------------------------------------------- M C 148

C H AN N EL AC T IVAT IO N AC K---------------------------------------------->

IM M ED IAT E ASSIG N C O M M AN DIM M ED IATE ASSIG N <---------------------------------------------- start T3101 M C 8B

<------------(A G CH)-------------

T3101expiry M C 149->“radio fa ilure

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

BCC: BTS Color Code

NCC: Network Color Code







RLE > SDCCH RF FailureMain causes > "Phantom RACH" > Channel Request due to handover

During HO, the first message sent to the target cell is HO AccessThis message is an Access Burst like Channel Request

If received on BCCH, can be understood as a Channel Request (RACH)A new case of "Phantom RACH"







RLE > SDCCH RF FailureMain causes > "Phantom RACH" > Channel Request due to handoverThis case is the most dangerous

The MS usually sends a sequence of HO Access messages, every frameIn some cases, this can create a phantom RACH if the frequency of the TCH is identical or adjacent to the one of interfered BCCHCharacteristics of such phantom RACH (Channel Required)

Subsequent frame numberRandom, but stable timing advance

Can block very easily SDCCH






Radio Link Establishment - BSS Failure

Main failure cases for Radio Link Establishment Radio Link EstablishmentSDCCH PhaseTCH assignmentAlerting/CNX Phase



Congestion

SDCCH Radio Failure

SDCCH Radio Failure

SDCCH BSS Problem

SDCCH BSS Problem






Radio Link Establishment - BSS Problem

RLE > BSS problem

No specific counter

MS BTS BSC MSCCHANNEL REQUEST

-------------(RACH)------------> CHANNEL REQUIRED----------------------------------------------> MC8C

CHANNEL ACTIVATION (SDCCH)<---------------------------------------------- MC148

CHANNEL ACTIVATION ACK---------------------------------------------->IMMEDIATE ASSIGN COMMAND

IMMEDIATE ASSIGN <---------------------------------------------- start T3101<------------(AGCH)------------- MC8B

SABM (L3 info)------------(SDCCH)------------>


BSS Problems are difficult to specify a priori. It is better to deduce them from other counters which are easier to implement and thus more reliable.






Radio Link Establishment - Counters

RLE counters

Request MC8C

GPRS causes P62CGSM invalid causes unknown

Preparation GSM valid causes unknown

Congestion MC04BSS Pb unknown

Execution Attempt MC148

Radio Access Failure MC149BSS Pb MC148 - (MC01+MC02) - MC149

Success MC01+MC02

Radio Link Establishment

REQUEST

Congestion

ATTEMPT

Radio access failure

SUCCESS

BSS problem

Preparation Failure

Execution Failure

GPRS causes GSM/GPRS invalid causes GSM valid causes

BSS problem


Statistically a ghost RACH can correspond to any kind of establishment cause: valid and invalid.

As ghost RACH which corresponds to a GSM valid cause will lead to an SDCCH allocation which will not be seized by an MS, it will lead to the incrementation of the MC149 counter and therefore counted as an SDCCH access failure due to radio.






Radio Link Establishment - Indicators

TYPICAL CALL FAILURES: RLE indicators

SDNAFLBNSDNAFLRNSDNACGNSDNAFSUNSDNAFLR


Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: GLOBAL Quality of service INDICATORS > SDCCH > Assignment Phase

SDNAUR: SDCCH assignment unsuccess rate

SDNACGR: SDCCH assignment failure rate due to congestion (Global)

SDNAFLRR: SDCCH assignment failure rate due to radio

SDNAFLBR: SDCCH assignment failure rate due to BSS problem

An SDCCH radio access failure due to ghost RACH occurrence is easily observed during low traffic hour (night time) since ghost RACHs are almost the only cause of failure.






SDCCH Phase - OC Success

Successful SDCCH phase: OC call

Transparent message: no dedicated counters

MS BTS BSC MSCSDCCH Phase : Originating Call case

< -------------------------------------------------------------------------------------------------------------------------AUTHENTICATION REQUEST

------------------------------------------------------------------------------------------------------------------------- >AUTHENTICATION RESPONSE

< -------------------------------------------------------------------------------------------------------------------------CIPHERING MODE COMMAND

------------------------------------------------------------------------------------------------------------------------- >CIPHERING MODE COMPLETE

------------------------------------------------------------------------------------------------------------------------- >SETUP

< -------------------------------------------------------------------------------------------------------------------------CALL PROCEEDING


Transparent messages (DTAP) are used in order the NSS performs control procedures to enable the MS to set up a speech call.

Authentication: Checks that the Mobile Station is the required station and not an intruder.

Ciphering: All Information (signaling, Speech and Data) is sent in cipher mode, to avoid monitoring and intruders (who could analyze signaling data).

Setup/Call Processing: call is being processed between the calling Party and the Called Party.






SDCCH Phase - TC Success

Successful SDCCH phase: TC call


MS BTS BSC MSCSDCCH Phase : Terminating Call case





< -------------------------------------------------------------------------------------------------------------------------SETUP

------------------------------------------------------------------------------------------------------------------------- >CALL CONFIRM


Setup/Call Confirm: the call is being processed between the Calling Party and the Called Party.






SDCCH Phase - LU Success

Successful SDCCH phase: Location Update


MS BTS BSC MSCSDCCH Phase : Location Update Case (with TMSI reallocation)

------------------------------------------------------------------------------------------------------------------------- >LOCATION UPDATE REQUEST





< -------------------------------------------------------------------------------------------------------------------------LOCATION UPDATE ACCEPT

------------------------------------------------------------------------------------------------------------------------- > TMSI REALLOCATION COMPLETE


Some transparent messages are also exchanged between the MS and the network in case of a Location Update transaction.






SDCCH Phase - Drops

SDCCH phase

Loss of connection during SDCCH phase = "SDCCH drop"

3 origins of SDCCH drop:Radio problems when connected on SDCCHBSS problemsCall lost during an SDCCH HO (handover failure without reversion to old channel)


Generally SDCCH handovers are disabled in the network since the average SDCCH duration is only around 2 to 3 seconds.






SDCCH Phase - Radio Drop

SDCCH phase > drop Radio

Connection lost due to Radio problem

MS BTS BSC MSCSDCCH Phase established

Radio connection lost---------------------------------------------------- > MC138CONNECTION FAILURE INDICATION

(cause : radio link failure)--------------------------------------- >CLEAR REQUEST

Cause : radio interface failure


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.






SDCCH Phase - BSS Drop

SDCCH phase > drop BSS

Connection lost due BSS problem


MC137

--------------------------------------- >CLEAR REQUEST

Cause : O&M interventionCause : radio interface failure


MC137 counts the number of SDCCH channel drops due to BSS problems.

A BSS problem can be a BTS/BSC hardware or software failure. It can also be due to a problem on the Abisinterface (due to Micro Wave transmission for instance).

BinhPT

Typewriter

Must with alarm






SDCCH Phase - HO drop

SDCCH phase > drop HO

Connection lost during Handover


HO FAILURE WITHOUT REVERSION MC07--------------------------------------- >

CLEAR REQUESTRadio Interface Message Failure (Alcatel)


MC07 counts the number of SDCCH channel drops due to handover failure.

BinhPT

Typewriter

No SDCCH HO






SDCCH Phase - Counters

SDCCH phase counters

SDCCH connection MC01+MC02+MC10

SDCCH Drop Drop radio MC138Drop BSS MC137Drop HO MC07

SDCCH Phase

TCH assignment phase SDCCH drop

SDCCH connection

Normal release

Drop radio

Drop BSS

Drop HO


BinhPT

Typewriter

Don't need to take care due to now don't use this

BinhPT

Typewriter

SDCCH Drop Rate = (MC138 + MC07 + MC137)/(MC01 +MC02) -- 4% 1. Find bad cell 2. Find cause Cause Drop rate SDCCH MC138 MC177 Cell 1: 2% Cell 2: 7% 2 23 BSS Check alarm on OMC Cell 3: 9% 45 1 Radio Do radio analysis

BinhPT

Rectangle

BinhPT

Line






SDCCH Phase - Indicators

SDCCH phase indicators

SDCDBNSDCDRNSDCDHNSDCDR


Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: GLOBAL Quality of service INDICATORS > SDCCH > Established phase

SDCDR: SDCCH drop rate (Global)

SDCDRR: SDCCH drop rate due to radio problem

SDCDBR: SDCCH drop rate due to BSS Problem

SDCDHR: 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






TCH Assignment - Success

TCH assignment success case

T3107: guard timer for TCH assignment

MS BTS BSC MSCTCH ASSIGNMENT PHASE (OC or TC)

< -----------------------------------ASSIGNMENT REQUEST

< --------------------------------------------------------PHYSICAL CONTEXT REQUEST

-------------------------------------------------------- >PHYSICAL CONTEXT CONFIRM

< --------------------------------------------------------MC703CHANNEL ACTIVATION (TCH)

-------------------------------------------------------- >CHANNEL ACTIVATION ACKNOWLEDGE

< -----------------------------------------------------------------------------------Start T3107(SDCCH) ASSIGNMENT COMMAND

---------------------- >TCH SABM -------------------------------------------------------- >

< ---------------------- ESTABLISH INDICATIONUA

----------------------------------------------------------------------------------- >Stop T3107ASSIGNMENT COMPLETE MC718

----------------------------------- >ASSIGNMENT COMPLETE

MC140a

MC140b

MC460a


MC703 counts the number of TCH channels activated (therefore allocated) in a cell.

MC718 counts the number of MSs which have successfully accessed a TCH in a cell as part of a call establishment (Normal Assignment).

Both counters are implemented at TRX level.

MC140a counts the number of normal assignment requests for TCH establishment.

MC140b counts the number of normal assignment commands for TCH establishment.

Both counters in order to discriminate BSS problems in Preparation and Execution phases.

MC460a is a counter for type 110: NB_TCH_EMERGENCY_HO_PRESERVATION: Definition: Number of high priority TCH requests served when:

the number of free TCH timeslots is less than or equal to NUM_TCH_EGNCY_HO.

the queue for this cell is not empty.

MC140a, MC140b and MC460 are given at Cell level.

BinhPT

HighLight

BinhPT

HighLight

BinhPT

HighLight

BinhPT

HighLight






TCH Assignment – Success for DTM

TCH assignment success case


MS BTS BSC MSCMFS

SDCCH Assignment Request

Phys. Context Conf

Chan. Act. (TCH)

Chan. Act. ACK

DR[Assignt CMD]Assignment CMD

SABM Est. IndicationUA

Assign CompleteDI[Assignt CMP] Assignment Complete

BSC Shared DTM Info Indication

Store TCH location in DTM

MS context

B10

MC140a

MC703 MC460a

Start T3107MC140b

Stop T3107

Start Trr1

Stop Trr1

New B10

BSCGP layer (B10), 07/04/2006 (ED 02 Proposal 01) (BSCGP) BSCDTM (= BSC Shared DTM Info Indication) …Multi Slot Information 10011111 Attribute Id Multi Slot Information00000001 Attribute Length 1000----- Spare 0---1---- 8PSK UL 8-PSK UL supported----10-- DTM EGPRS Multi Slot Class Sub-Class 9 supported------10 DTM GPRS Multi Slot Class Sub-Class 9 supportedCS cause 10100001 Attribute Id CS cause00000001 Attribute Length 1-----011 cause Normal assignment (TCH)00000--- Spare 0TCH Location 10010110 Attribute Id TCH Location00000001 Attribute Length 1----0000 TRX ID 0-111---- TN 70------- Spare 0






TCH Assignment - TCH Congestion

TCH assignment > congestion

4 causes of congestion ⇒ 4 counters: C612A, B, C, DwheneverQueuing is not allowedQueue is FullT11 expiresRTCH request is removed from the queue due to a higher priority request to be queued


< -----------------------------------------------ASSIGNMENT REQUEST

No RTCH available on requested cell MC812

------------------------------------------------ >ASSIGNMENT FAILURE

Cause No Radio Resource Available


C612E: Number of 08.08 ASSIGNMENT REQUEST for TCH normal assignment rejected due to congestion on the Abisinterface. (from B8)

Therefore B6 counter MC612 is replaced by MC812 from B7. MC812 = C612A+C612B+C612C+C612D+C612E of PM Type 1.

But as C612E was in restriction in B8 (always = 0) then MC812(B7) = MC612(B6)

MC612A, MC612B, MC612C, MC612D also exist in PM Type 110.

A TCH request is attached a Priority Level from 1 (highest priority) to 14 (lowest priority).

BinhPT

Typewriter

TCH Congestion Add TCH Increase outgoing HO Queue control - keep MS in the Queue list to wait the free TCH or do DR Forced_QUEUEING : EN: start queueing MC612A 0 Dis: stop queueing MC612A N T11_Forced Max waiting time in the Queue list ( <20s) MC612C BTS_Queue_Length Max MS nbs in the Queue list ( <10) MC612B

BinhPT

HighLight

BinhPT

Typewriter

Example: MC612A MC612B Mc612C TCH Cong ( 5%) BTS_Q_L T11_Forced Forced_QU Cell1: 0 12 3 6% Increase (INC) INC Cell2: 0 0 8 6% INC Cell3: 21 0 0 6% Enable Cell4: 0 2 0 1%






TCH Assignment – Exercise


TCH assignment > congestion

Causes of High TCH congestion Items to check

Incorrect configuration of trunk circuit data at A interface

Co-frequency and co-BSIC lead to TCH assignment failure in handover

Board fault or unstable performance causes the high congestion rate

BTS hardware is not properly installed, which causes uplink/downlink signal level unbalance and TCH congestion.

The transmitting power of BCCH TRX is too much higher than that of TCH TRX in the same cell.

Interference causes the congestion

TCH assignment failure due to isolated site and complicated topography result in a high congestion rate

The causes of high TCH congestion can be checked using 2 different kinds of items:

Either analyze the causes of congestion remotely

Traffic statistics

Alarm information

BTS remote maintenance on OMC

Abis interface message analysis

Or check the BTS on-site






TCH Assignment - Radio Failure

TCH assignment > radio failure

Radio problem





< -------------------------------------------------------- MC703CHANNEL ACTIVATION (TCH)


< ----------------------------------------------------------------------------------- Start T3107 (SDCCH) ASSIGNMENT COMMAND

SABM----(TCH)------X

T3107 ExpiryMC746B----------------------------------- >

ASSIGNMENT FAILURERadio interface failure

MC140a

MC140b


MC746B counts the number of TCH access failures due to radio problems.

The MC746B counter is implemented at TRX level from B7.

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.

BinhPT

Typewriter

MC746B and MC736 - Radio fault 1. Check both counter on TRX ( For BBH cell, need change to No Hopping cell ) 1) 1 TRX fault --> Drop/ fault in frequency --> HW fault (TRE ) or interference --> change f or MAIO 2) n TRX on 1 ANT fault -> HW fault ( cable or atten..) 3) random TRX or all have fault --> must analysis again --> standard radio fault






TCH Assignment - BSS Problem

TCH assignment > BSS problem

BSS problem (Abis, BTS/BSC HW or SW)





< -------------------------------------------------------- MC703CHANNEL ACTIVATION (TCH)



SABM----(TCH)---- >

MC14B

MC140a

MC140b

No specific counter


The number of TCH Assignment failures due to BSS problem can be correctly deduced and distinguished for preparation and execution phases from B8 with the 2 counters MC140a and MC140b.(see the next slide)

B7 counter MC14b has been removed.






TCH Assignment - Counters

TCH assignment counters

Congestion

ATTEMPT

Radio access failure

SUCCESS

BSS problem

Preparation Failure

Execution Failure

REQUEST

BSS problemTCH Assignment

Preparation Request MC140a

Congestion MC812

BSS Pb MC140a-MC140b-MC812

Execution Attempt MC140b

Radio Access Failure MC746b

BSS Pb MC140b-MC718-MC746b

Success MC718







TCH Assignment - Indicators

TCH Assignment indicators

TCNAFLBN

TCNAFLRN

TCNACGN

TCAHCAN

TCNAUR


Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: GLOBAL Quality of service INDICATORS > RTCH > Assignment Phase

TCNAUR: TCH assignment unsuccess rate (Global)

TCNACGR: TCH assignment failure rate due to congestion

TCNAFLRR: TCH assignment failure rate due to radio problems

TCNAFLBR: TCH assignment failure rate due to BSS problems

From B7.2 some indicators can be provided on a per TRX basis due to the availability of counters provided per TRX in Type 110:

TCNAEFR = RTCH_assign_efficiency_rate (RNO name) = MC718 / MC703

Rate of successful RTCH seizures in relation to all RTCHs allocated, during the TCH assignment procedure.

TCNAAFLRR = RTCH_assign_allocated_fail_radio_rate (RNO name) = MC746B / MC703

Rate of RTCH seizures failed during the normal assignment procedure because of radio problems in relation to all RTCHs allocated for TCH assignment procedure.

This will help a lot detect bad QOS due to TRX hardware-related problem.






TCH Assignment - Exercise

TCH assignment failure and BSC Shared DTM message 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).

3) In file 7, identify and give the content of the BSC Shared DTM Info Indication message.

Time allowed:

15 minutes

B10


New B10






TCH Phase - Success

TCH phase:OC

TC

Transparent messages for BSS, no specific countersTCH DROP: any problem occurring after TCH assignment (during or after connection) cannot be discriminated

MS BTS BSC MSCAlerting Connection Phase (OC case) : ringing phase

< ---------------------------------------------------------------------------------------------------------------------------ALERTING

< ---------------------------------------------------------------------------------------------------------------------------CONNECT

--------------------------------------------------------------------------------------------------------------------------- >CONNECT ACK

MS BTS BSC MSCAlerting Connection Phase : TC case

--------------------------------------------------------------------------------------------------------------------------- >ALERTING

--------------------------------------------------------------------------------------------------------------------------- >CONNECT

< ---------------------------------------------------------------------------------------------------------------------------CONNECT ACK






< --------------------------------------------------------CHANNEL ACTIVATION (TCH)



---------------------- >TCH SABM -------------------------------------------------------- >

< ---------------------- ESTABLISH INDICATIONUA

----------------------------------------------------------------------------------- > Stop T3107ASSIGNMENT COMPLETE

----------------------------------- >ASSIGNMENT COMPLETE

< ---------------------------------------------------------------------------------------------------------------------------ALERTING

< ---------------------------------------------------------------------------------------------------------------------------CONNECT

---------------------------------------------------------------------------------------------------------------------------->CONNECT ACK

Call Setup

Call phase

Call Setup

Call phase

The Call setup phase and the Stable call phase are not corresponding between the BSS and the NSS.

For the BSS, a call is established when the MS has successfully accessed a TCH channel on the Air interface.

For the NSS, a call is established when the speech data exchanged is started between end users.

Thus the Call setup phase is shorter and the Call phase is longer in the BSS.

Therefore the Call Setup Success rate is worse in the NSS and the Call Drop rate is worse in the BSS.






TCH Phase - Radio Drop

TCH phase > drop radio

Radio problem

MS BTS BSC MSCAlerting Connection Phase or Communication : at any time

Radio problem-------------------------------------------------------- > MC736

CONNECTION FAILURE INDICATION --------------------------------------- >Cause radio link failure CLEAR REQUEST

Cause radio interface failure(alcatel)


MC736 counts the number of TCH channel drops due to radio problems.

The MC736 counter is implemented at TRX level.

Radio problems can be due to coverage, interference and sometimes BSS dysfunction which is not detected as a system alarm by the O&M Fault Management application.






TCH Phase - Remote TC Drop

TCH phase > drop TC

Remote TransCoder problem


Radio problem-------------------------------------------------------- > MC739

CONNECTION FAILURE INDICATION --------------------------------------- >Remote transcoder failure CLEAR REQUEST

Equipment failure


MC739 counts the number of TCH channel drops due to BSS problems reported as "remote TransCoder failure".


It can usually be a bad quality of the transmission on the Abis interface (Micro Wave) or a faulty hardware component in the TransCoder or even sometimes BSS software/hardware problems.






TCH Phase - BSS Internal Drop

TCH phase > drop BSS internal

Other internal BSS problem (excluding TC)


MC14C--------------------------------------- >

CLEAR REQUESTO&M intervention

Radio interface failure


MC14C counts the number of TCH channel drops due to BSS problems other than the ones reported by the TransCoder.

A BSS problem can be a BTS/BSC hardware or software failure.






TCH Phase - HO Drop

TCH phase > drop HO

Handover failure


HO FAILURE WITHOUT REVERSION MC621--------------------------------------- >

CLEAR REQUESTRadio Interface Message Failure (Alcatel)


MC621 counts the number of TCH channel drops due to Handover failure.


This event is also counted in the set of Handover counters as an Outgoing handover failure without reversion to the old channel.






TCH Phase - Preemption Drop

TCH phase > drop preemption

TCH preempted

MS BTS BSC MSCAlerting Connection Phase of a call

with priority level pl2 and preemption vulnerability indicator pvi=1no TCH free

ASSIGNMENT REQUEST<---------------------------------------

Priority level pl1 > pl2preemption capability indicator pci=1

MC921C--------------------------------------- >

CLEAR REQUESTpreemption


MC921C counts the number of TCH channel drops due to preemption for another call to be established.

The MC921C counter exists from B7 as linked to the feature Preemption.

BinhPT

Typewriter

TCH Drop BSS MC14c Check and solve alarms TC MC739 Abis Trans problems A if Trans or units ( MSC or TC problems )

BinhPT

Typewriter

BinhPT

Typewriter

1. Check if Abis or A problems Abis fault - linked BTS aways fault A fault - any BTS can have fault

BinhPT

Typewriter

9:00 10:00 11:00 MC739 MC739 MC739

BinhPT

Typewriter

Abis

BinhPT

Typewriter

Cella Cellb Cellc1 Cellc2 Cellc3 Celld

BinhPT

Typewriter

a b c c c d

BinhPT

Typewriter

4 3 2 1 0 0 1 0 2 0 1 0 0 0 3 0 0 3

BinhPT

Typewriter

Abis a fault A fault Abis c fault Abis c fault Abis c fault A fault

BinhPT

Typewriter

2. A detect by TYPE 18

BinhPT

Typewriter

- pages 240 B10 Counter

BinhPT

Typewriter

BinhPT

Typewriter

LINK ID = 32*A if No (from 1 to N) + TS No, start with number 33 ( TS0 --> 32 only for Trans control TS1--> 33 TS2--> 34... )

BinhPT

Typewriter

BinhPT

Typewriter

C750 C751

BinhPT

Typewriter

C750/C751

BinhPT

Typewriter

104 2045 30 68.1667 105 1815 28 106 1120 0 invalid 107 320 100 3.2

BinhPT

Typewriter

(not use for traffic)

BinhPT

Typewriter

Fault ( < 10s )

BinhPT

Typewriter

---> LINK ID 107 fault 107 = 32 x 3 + 11 ---> TS 11 in E1 Fault

BinhPT

Typewriter

Time

BinhPT

Typewriter

Nb

BinhPT

Typewriter

Time for MS

BinhPT

Typewriter

3. Get a fault ACH list, do following steps 1) check related TC Unit ( MT120 ) 2) If TC Units are OK then if a little ACHs fault, we need lock them both TC and MSC if a lot ACH fault, need MSC engineer solve






TCH Phase - Counters

TYPICAL CALL FAILURES: TCH phase counters

TCH connection MC718+MC717A+MC717B

Outgoing HO success MC712

Call drop Drop radio MC736Drop TC MC739Drop internal BSS MC14CDrop HO MC621Drop preemption MC921C

Normal release unknownNSS abnormal release unknown

TCH Phase

Outgoing HO success Call drop

TCH connection

Normal release

Call drop radio

Call drop BSS

Call drop HO

Call drop preemption

TC

BSS internal

NSS abnormal release







TCH Phase - Call Drop Rate

TYPICAL CALL FAILURES: TCH phase indicators

Call drop rate = call drop / RTCH success end

RTCH success end = RTCH assignment success + RTCH incoming (HO+DR) success - RTCH outgoing HO

Incoming internal HO+DR

BSS1 BSS2

Incoming external HO+DR

outgoing HO

TCH assignment


QSCDN = call drop

= drop radio + drop TC + drop internal BSS + drop HO + drop Preemption

= MC736 + MC739 + MC14C + MC621 + MC921C

TCQHCCN = RTCH success end

= assignment success + incoming (HO+DR) success - outgoing HO

= MC718 + (MC717A+MC717B) - MC712

As MC718, MC717A, MC717B and MC712 are provided per TRX, the “RTCH success end” indicator (TCAHCCN) can be computed per TRX.

But since only MC736 (drop radio), MC739 (drop TC) and MC621 (drop HO) are provided per TRX, the “call drop rate” indicator (QSCDR) can be computed per CELL only.

On the other hand, the following call drop indicators can be computed per TRX:

call drop radio rate (QSCDRR) = call drop radio / RTCH success endcall drop HO rate (QSCDHR) = call drop HO / RTCH success end call drop TC rate (QSCDBTR) = call drop TC / RTCH success end

Note:

MC718 counts the number of successful TCH assignments.

MC717A counts the number of successful internal DRs.

MC717B counts the number of successful incoming internal and external (HOs+DR) as well as the number of intra cell HOs successfully performed.

MC712 counts the number of successful outgoing internal and external HOs as well as the number of intra cell HOs successfully performed.






TCH Phase - RTCH Drop Rate


RTCH drop rate = call drop / RTCH success begin

RTCH success begin = RTCH assignment success+ RTCH incoming (HO+DR) success- RTCH intra cell HO success

BSS1 BSS2


TCH assignmentIncoming external HO+DR

outgoing HO

Intra-cell HO


QSCDN = call drop


= MC736 + MC739 + MC14C + MC621 + MC921C

TCQHSUBN = RTCH success begin

= assignment success + incoming (HO+DR) success - intra cell HO

= MC718 + (MC717A+MC717B) - MC662

As MC662 is not provided per TRX, the “RTCH success begin” indicator (TCAHSUBN) cannot be computed per TRX but per CELL only.

Therefore all “RTCH drop rate” indicators can be computed per CELL only.

Note:

MC662 counts the number of successful TCH intracell HOs.






TCH assignment

outgoing HOBSS1 BSS2

Incoming external HO+DR


TCH Phase - TRX TCH Drop Rate


TRX TCH drop rate = call drop / RTCH success

RTCH success = RTCH assignment success+ RTCH incoming (HO+DR) success

Intra-cell HO


QSCDN = call drop


= MC736 + MC739 + MC14C + MC621 + MC921C

TCAHSUN = RTCH success

= assignment success + incoming (HO+DR) success

= MC718 + (MC717A+MC717B)

Whereas some call drop rate indicators are defined per TRX and per CELL, TRX RTCH drop rate indicators are defined at TRX level only.

As MC718, MC717A, MC717B are provided per TRX, the “RTCH success” indicator (TCAHSUN) can be computed per TRX.

But since only MC736 (drop radio), MC739 (drop TC) and MC621 (drop HO) are provided per TRX, a global “TRX RTCH drop rate” indicator cannot be provided.

On the other hand, the following TRX RTCH drop indicators can be computed: TRX_RTCH_drop_radio_rate (TCAHCDRTR) = call drop radio / RTCH successTRX_RTCH_drop_HO_rate (TCHOCDTR) = call drop HO / RTCH success

TRX_RTCH_drop_BSS_remote_TC_rate (TCTRTCDTR) = call drop TC / RTCH success

CAUTION: Intra-cell HO being counted in MC717B and not deduced in the RTCH success computation in order to provide the TRX RTCH drop indicators at TRX level then these indicators may be abnormally low (good) if a large amount of intra-cell HOs are performed in the cell (concentric cell, multiband cell).



Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS.

call drop indicators: all of them are available per CELL only and some of them per TRX

GLOBAL Quality of service INDICATORS > Call Statistics > Call drop

QSCDR: call drop rate (Global): CELL

QSCDRR: call drop rate due to radio: CELL + TRX

QSCDBIR: call drop rate due to BSS internal problem: CELL

QSCDBTR: call drop rate due to TransCoder reported problem: CELL + TRX

QSCDHR: call drop rate due to HO failure: CELL + TRX

QSCDPR: call drop rate due to preemption: CELL

RTCH drop indicators: all of them are available per CELL only

GLOBAL Quality of service INDICATORS > RTCH > Established phase

QSTCCDR: RTCH drop rate

TCAHCDRR: RTCH drop rate due to radio problem

TCTRICDBR: RTCH drop rate due to BSS internal problem

TCTRTCDR: RTCH drop rate due to TransCoder reported problem

TCHOCDR: RTCH drop rate due to HO failure

TCPPCDR: RTCH drop rate due to preemption

TRX TCH drop indicators: all of them are available per TRX only

GLOBAL Quality of service INDICATORS > RTCH > Established phase

TCAHCDRTR: TRX TCH drop rate due to radio problem

TCTRTCDTR: TRX TCH drop rate due to TransCoder reported problem

TCHOCDTR: TRX TCH drop rate due to HO failure






TCH Phase - Exercise

Alerting/Connection: TCH drop

With K1205 (file PAIB29.REC)1) For a Radio TCH drop, give the message and the cause. Extract a call with this cause.

Can you say if it is occurring during the communication phase? 2) Find a TCH drop due to Handover and extract the call.3) Find a TCH drop due to TC problem and extract the call:

Can you identify PCM, CIC?How many TC PBs are there in this Trace?Any remark about PCM and CIC?

Time allowed:

15 minutes







Summary

TYPICAL CALL FAILURES: summary

Call stage A interface Cause field Related problem

radio linkestablishment

no message - SDCCH congestionradio problem- Dummy rach

SDCCH phase Clear Request - radio interface failureradio interface failure- O&M intervention

- radio problem- BSS system HW/SW pb- recovery/operator

TCH assignment Assignment Failure - no radio resource avalaible- Radio Interface Failure

- TCH congestion- Radio problem

Alerting/connectioncall established

Clear Request - radio interface failureradio interface message failure-equipment failure

- O&M interventionradio interface failure- preemption

- radio problem- HO failure w/o reversion

- Transcoder failure-operator action/recovery

- BSS system HW/SW pb-preemption

LAPD counter to analyze the cause of call establishment failures


When the BSC is congested on the downlink, some messages are discarded. This may result for example in call establishment failures, loss of paging messages or delay in handover procedures.

An LapD counter that indicates the time an LapD link is congested is created to analyze the cause of a degradedquality of service. This counter is implemented in type 7 and thus is only available in a detailed measurement campaign.

Counter: L1.18: TIME_LAPD_CONG

Definition: Time in seconds during which the LapD link is congested in transmission in the BSC.





4 Description of Global Indicators






Reminder

Global Indicators areA set of indicators selected by Alcatel-LucentUseful to monitor the overall network

What are the user and or system impacts if a Global Indicator (GI) is bad?






SDCCH Congestion Rate

SDCCH CONGESTION rate: may have impact for subscriberCall setup failure only after 3 subsequent congestionsIf not, only some extra delay for call establishment

(less than 1 second) without immediate_assign_rejectCan be longer with reject (but usually short values are used for call request)

INDICATOR(G)

SDCCH ASSIGN CONG FAIL RATE

DEFINITION Rate of SDCCH not allocated during radio link establishment procedure due to congestion on theAir interface

FORMULA Σ cell(MC04) / SDCCH ASSIGN REQUESTSTHRESHOLD > 5%COMMENT 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 highrate of « phantom RACH »)

REF NAME SDNACGR UNIT %

(G) means that the indicator is Global, i.e. it is important to provide it at Network level.

INDICATOR SDCCH ASSIGN REQUESTS

DEFINITION Number of SDCCH seizure requests during radio link establishment procedureFORMULA Σ

cell(MC148 + MC04)

THRESHOLDCOMMENT This includes requests rejected due to congestion on SDCCHREF NAME SDNARQN UNIT Number

BinhPT

HighLight

BinhPT

Typewriter

= MC04/MC8C






SDCCH Congestion Rate

SDCCH CONGESTION rate

SDNARQN

SDCGMR

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:GLOBAL Quality of service INDICATORS > SDCCH > Assignment phase

SDNACGR: SDCCH assignment failure rate due to congestion (Global)






SDCCH Drop Rate

INDICATOR(G)

SDCCH DROP RATE

DEFINITION Rate of dropped SDCCH (SDCCH is established for any transaction OC, TC, LU,etc.)FORMULA Σcell (MC138 + MC07 + MC137) / SDCCH ASSIGN SUCCESSTHRESHOLD > 4%COMMENT Drop radio + Drop HO + Drop BSSREF NAME SDCDR UNIT %

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 (several tens of seconds).

INDICATOR SDCCH ASSIGN SUCCESS

DEFINITION Total number of SDCCHs successfully seized by mobile during radio link establishmentprocedure

FORMULA Σcell (MC01 + MC02)

THRESHOLDCOMMENTREF NAME SDNASUN UNIT Number






TCH Assign Unsuccess Rate

TCH ASSIGN UNSUCCESS rate: congestionradio problemBSS problems

INDICATOR(G)

TCH ASSIGN UNSUCCESS RATE

DEFINITION Rate of unsuccessful RTCH seizures for normal assignment purpose (congestion + HO&radiofailures)

FORMULA B7.2 (TCH ASSIGN REQUESTS – TCH ASSIGN SUCCESS) / TCH ASSIGN REQUESTSTHRESHOLD > 3%COMMENTREF NAME TCNAUR UNIT %

In a dense network, the TCH assignment unsuccess rate should be lower than 1%.

INDICATOR

TCH ASSIGN SUCCESS

DEFINITION Number of TCH successfully seized by MS for normal assignment procedure. FORMULA B8 Σ TRX (MC718) THRESHOLD COMMENT REF NAME TCNASUN UNIT Number

I N D I C A T O R T C H A S S I G N R E Q U E S T S

D E F I N I T I O N N u m b e r o f T C H s e iz u r e r e q u e s ts f o r n o r m a l a s s ig n m e n t p r o c e d u r e .

F O R M U L A B 8 Σ c e ll M C 1 4 0 a

T H R E S H O L D

C O M M E N T M C 1 4 0 a : n e w c o u n te r in t r o d u c e d in B 8 r e le a s e .M C 1 4 0 a ( ty p e 1 1 0 ) : N B _ T C H _ N O R _ A S S _ R E Q th a t in d ic a te s th e n u m b e r o f n o r m a l a s s ig n m e n t r e q u e s ts f o r T C H e s ta b l is h m e n t ( in H R o r F R u s a g e )

R E F N A M E T C N A R Q N U N I T N u m b e r

I N D I C A T O R T C H A S S I G N R E Q U E S T S

D E F I N I T I O N N u m b e r o f T C H s e iz u r e r e q u e s ts f o r n o r m a l a s s ig n m e n t p r o c e d u r e .

F O R M U L A B 8 Σ c e ll M C 1 4 0 a

T H R E S H O L D

C O M M E N T M C 1 4 0 a : n e w c o u n te r in t r o d u c e d in B 8 r e le a s e .M C 1 4 0 a ( ty p e 1 1 0 ) : N B _ T C H _ N O R _ A S S _ R E Q th a t in d ic a te s th e n u m b e r o f n o r m a l a s s ig n m e n t r e q u e s ts f o r T C H e s ta b l is h m e n t ( in H R o r F R u s a g e )

R E F N A M E T C N A R Q N U N I T N u m b e r

I N D I C A T O RI N D I C A T O R T C H A S S I G N R E Q U E S T ST C H A S S I G N R E Q U E S T ST C H A S S I G N R E Q U E S T S

D E F I N I T I O ND E F I N I T I O N N u m b e r o f T C H s e iz u r e r e q u e s ts f o r n o r m a l a s s ig n m e n t p r o c e d u r e . N u m b e r o f T C H s e iz u r e r e q u e s ts f o r n o r m a l a s s ig n m e n t p r o c e d u r e .

F O R M U L A B 8F O R M U L A B 8 Σ c e ll M C 1 4 0 aΣ c e ll M C 1 4 0 a

T H R E S H O L DT H R E S H O L D

C O M M E N TC O M M E N T M C 1 4 0 a : n e w c o u n te r in t r o d u c e d in B 8 r e le a s e .M C 1 4 0 a ( ty p e 1 1 0 ) : N B _ T C H _ N O R _ A S S _ R E Q th a t in d ic a te s th e n u m b e r o f n o r m a l a s s ig n m e n t r e q u e s ts f o r T C H e s ta b l is h m e n t ( in H R o r F R u s a g e )

M C 1 4 0 a : n e w c o u n te r in t r o d u c e d in B 8 r e le a s e .M C 1 4 0 a ( ty p e 1 1 0 ) : N B _ T C H _ N O R _ A S S _ R E Q th a t in d ic a te s th e n u m b e r o f n o r m a l a s s ig n m e n t r e q u e s ts f o r T C H e s ta b l is h m e n t ( in H R o r F R u s a g e )

R E F N A M ER E F N A M E T C N A R Q NT C N A R Q N U N I TU N I T N u m b e rN u m b e r






Global Radio Congestion Level

GLOBAL RADIO CONGESTION LEVEL (TCH congestion rate)Subscriber impact: call setup failureMore a management indicator: % of network which has congestion

INDICATOR(G)

GLOBAL RADIO CONGESTION LEVEL

DEFINITION Global radio congestion level : number or rate of cells recurrently congestedFORMULA COUNT_OF_CELLS (AVERAGE (MAX (TCH ASSIGN FAIL CONG RATE)) > 2%))THRESHOLD According to operatorCOMMENT This indicator reports the global radio congestion rate on the network. We define a specific

indicator counting the number of cells that are in congestion in a recurrent manner.MAX (TCH ASSIGN FAIL CONG RATE) : is the peak of failures due to congestion observedduring the period (the day normally). See the definition of TCH ASSIGN FAIL CONG RATE in the

Quality of Service chapter)AVERAGE: is an averaging function of the blocking rate over the selected period, that is over BHof days for a week, or over BH of weeks for a monthCOUNT_OF_CELL : is a function counting the number of cells for which condition between () isrespected.

The number of cells can be used as indicator, or the rate of cells over the total number of cells in thenetwork or area.

REF NAME QSCGR UNIT Number

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.






Call Drop Rate

CALL DROP rate: The most important indicatorUsed with call setup success rate to compare PLMN (GSM and other one)Subscribers impact: call drop!!

INDICATOR(G)

CALL DROP RATE

DEFINITION radio+ HO +Rate of dropped calls (system + preemption) over the total amount of calls with asuccessful end

FORMULA Scell (MC621 + MC14c + MC736 + MC739 + MC921c) / TCH SUCCESS ENDTHRESHOLD > 4%COMMENT Drop system + Drop radio + Drop HO + Drop preemption

TCH drops occurring after successful assignment but before speech connection are considered ascall drops even if from the customer point of view it is a call setup failureMC739, MC736 and MC621 derive from B6 counters C139, C136 and C21. These new countersare per TRX

MC921c was new in B7.2REF NAME QSCDR UNIT %

In a dense network, the Call Drop Rate should be lower than 2%. It should even go down to 1% or less in case Slow Frequency Hopping is used.

The RTCH drop rate is defined below:

The TRX TCH drop radio rate is defined below:

INDICATOR GLOBAL TCH DROP

DEFINITION Rate of TCHs dropped (system + radio + handover + preemption) over the total amount ofcalls established in the cell

FORMULA Σcell (MC14c + MC739 + MC736 + MC621+ MC921c) / TCH SUCCESS BEGIN

THRESHOLD > 3%COMMENT Drop System + Drop radio + Drop HO + Drop preemption

Indicator relevant at cell level mostly.MC739, MC736 and MC621 derive from B6 counters C139, C136 and C21. These new

counters are per TRXMC921c is new in B7.2

REF NAME QSTCCDR UNIT %

INDICATOR TRX TCH DROP RADIO RATE

DEFINITION Rate of TCHs dropped due to radio problems, per TRXFORMULA (MC736) / TCH SUCCESS

THRESHOLD > 3%COMMENT New from B7

MC736 derives from B6 counters C136. This new counter in B7 is per TRX.Indicator only per TRX because intracell handovers are taken into account

REF NAME TCAHCDRTR UNIT %






Call Setup Success Rate

CALL SETUP SUCCESS rate: the second most important indicatorUsed to compare PLMNSubscriber: 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)

INDICATOR(G)

CALL SETUP SUCCESS RATE (BSS view)

DEFINITION Rate of calls going until TCH successful assignment, that is not interrupted by SDCCH DROPneither by Assignment failures

FORMULA (1 – ( SDCCH DROP / SDCCH ASSIGN SUCCESS ) ) * (1 TCH ASSIGN UNSUCCESS RATE)

THRESHOLD > 95%COMMENT SDCCH assignment failures 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

REF NAME QSCSSR UNIT %

Ghost Racks which correspond to a valid establishment cause are not identified by the BSS. Therefore they can lead to a high SDCCH assignment failure rate if they are too numerous.

As the end user is not impacted by this phenomenon if no SDCCH congestion is induced, the SDCCH assignment phase is not considered in the computation of the Call Setup Success rate provided by Alcatel-Lucent tools.

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

The SDCCH congestion rate should also be considered to have a complete picture of Call Setup efficiency.






Call Success Rate

CALL SUCCESS rate:1 call success =

1 call successfully establishedWithout any call drop

INDICATOR(G)

CALL SUCCESS RATE (BSS view)

DEFINITION Rate of calls going until normal release , that is not interrupted by SDCCH DROP, neither byAssignment Failures nor by CALL DROP

FORMULA (CALL SETUP SUCCESS RATE) * (1 – CALL DROP RATE)THRESHOLD < 92%COMMENTREF NAME QSCCR UNIT %

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






Call (Setup) Success Rate

CALL SETUP SUCCESS rateCALL SUCCESS rate

TCAHSUN

QSCCR

QSCSSR

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:GLOBAL Quality of service INDICATORS > Call statistics > Call success

QSCSSR: Call setup success rate (Global)

QSCCR: Call success rate (Global)






Handover Cause Distribution

Indicator aiming at measuring the efficiency of planning /optimization

INDICATOR(G)

HO CAUSE DISTRIBUTION

DEFINITION Distribution of Handover attempts by cause X : UL/DL Qual, UL/DL Lev, UL/DL Interference,Distance, Better Cell, Interband, Micro cells HO, Concentric cell, Traffic, AMR, TFO causes.

FORMULA B7.2 Σ cell (MC67w or MC785x or MC586y or MC10zz or MC447 or MC461)Σcell (MC67all + MC785all + MC586all + MC10all + MC447 + MC461)

MC67all = MC671+MC672+MC673+MC674+MC675+MC676+MC677+MC678+MC679+MC670MC785all = MC785a + MC785d + MC785e + MC785f (microcell)MC586all = MC586a + MC586b + MC586c (concentric)MC10all = MC1040 + MC1044 + MC1050

THRESHOLD Quality DL > 10%, Qual UL > 10%, Level UL > 20%, Level DL > 20%Interf UL > 5%, Interf DL > 5%, Better Cell < 30%

COMMENTREF NAME HCSTBPBR, HCCCELVDR, HCCCELVUR, HCCCBCPR,

HCSTEDIR, HCSTEIFDR, HCSTELVDR, HCSTEQLDR,HCSTBDRR, HCMBBCPR, HCMCEBSR, HCMCELVDR,HCMCBCPR, HCMCELVUR, HCSTEMIR, HCSTEIFUR,HCSTELVUR, HCSTEQLUR, HCSTAMR, HCSTBTFR

UNIT %






Handover Standard Cause Distribution

Indicator aiming at measuring the efficiency of planning / optimizationInteresting for comparing HO distribution after concentric or micro cell implementation

INDICATOR(G)

DISTRIBUTION HO CAUSE STANDARD

DEFINITION Distribution of Handover attempts by standard cause : Power Budget, quality too low, level too low,high interference and MS-BTS distance too long.

FORMULA B7.2Σ cell ( (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)

THRESHOLDCOMMENTREF NAME HCSTEIFDSR, HCSTEIFUSR, HCSTEIFSR, HCSTELVDSR,

HCSTELVUSR, HCSTELVSR, HCSTEQLDSR,HCSTEQLUSR, HCSTEQLSR, HCSTBPBSR, HCSTEDISR

UNIT %

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

HCSTEIFR

HCSTEQLR

HCSTELVR

HCSTEDMR

HCSTBPBR

HCMCR

HCCC

TMHOSR

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:Handover statistics INDICATORS > Handover causes

HCXXYYYYR: 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

Success rate of execution of Outgoing HO

INDICATOR(G)

OUTGOING HO SUCCESS RATE

DEFINITION Rate of successful outgoing external and internal intercell SDCCH and TCH handoversFORMULA B7.2 Σcell (MC646 + MC656) / Σcell (MC645a + MC655a)THRESHOLD < 90%COMMENT This indicator includes preparation and execution.REF NAME HOORSUR UNIT %

INDICATOR(G)

EFFICIENCY OF OUTGOING HANDOVER EXECUTION

DEFINITION Rate of successful outgoing external and internal intercell SDCCH and TCH handoversFORMULA Σcell (MC646 + MC656) / Σcell (MC650 + MC660)

THRESHOLD < 90%COMMENT This indicator takes into account HO execution only (not ho preparation).REF NAME HOOREFR UNIT %

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.

From B7 MC645A replaces MC645 of B6.






Incoming Handover Success Rate

Global success rate of Incoming HO

Success rate of execution of Incoming HO

INDICATOR(G)

INCOMING HANDOVER SUCCESS RATE

DEFINITION Rate of successful incoming external and internal intercell SDCCH and TCH handovers.FORMULA Σcell(MC642 + MC652) / Σcell(MC820 + MC830)

THRESHOLD < 90%COMMENTREF NAME HOIRSUR UNIT %

INDICATOR(G)

EFFICIENCY OF INCOMING HANDOVERS

DEFINITION Rate of successful incoming external and internal intercell SDCCH and TCH HOsFORMULA Σcell (MC642 + MC652) / Σcell(MC821 + MC831)THRESHOLD < 90%COMMENT Excluding congestion failures and BSS preparation failures from requests.REF NAME HOIREFR UNIT %

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.






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

CoverageCoverage 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 it’s 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.






Call Quality Factor Absolute

The highest, the best is the cellBut the traffic handled is not taken into account

INDICATOR(G)

CELL QUALITY FACTOR ABSOLUTE

DEFINITION Indicator summarizing the cell behavior and allowing the operator to sort out cell for investigation.This indicator is based on failure events. For each part of the indicator,twothresholds are used: Topt and TQoS. TQoS is the QoS warning threshold (e.g. above or

belowthe threshold, a warning is generated on the cell. Topt + TQoS is the optimal valuethat should be acheived. Each part as a weighting factor (WF) according to the

impact on the subscriber’s point of view.

FORMULA ((1 – SDCCH CONGESTION rate) - TQoS)/ Topt * WF+ (CALL SETUP SUCCESS rate - TQoS)/ Topt *WF+ ((1 – CALL DROP rate - TQoS)/ Topt * WF+ (OUTGOING HO SUCCESS rate - TQoS)/ Topt * WF+ ((1 – HO QUALITY rate - TQoS)/ Topt * WF

THRESHOLD SDCCH CONGESTION rate : TQoS= 0.97, Topt= 0.03, WF = 0.1CALL SETUP SUCCESS rate : TQoS= 0.9, Topt= 0.09, WF = 0.2CALL DROP rate : TQoS= 0.96, Topt= 0.04, WF = 0.3

OUTGOING HO SUCCESS rate : TQoS= 0.85, Topt= 0.12, WF = 0.15HO QUALITY rate : TQoS= 0.85, Topt= 0.1, WF = 0.25

COMMENTREF NAME QSCQAR UNIT %

This counter intends to compute for every cell of the network a global indicator taking into account the major causes of bad Quality of Service.

Each cause is weighted according to the impact on the end user.






Call Quality Factor Relative

For optimizationTry to improve cells with the worst CQFR

INDICATOR(G)

CELL QUALITY FACTOR RELATIVE

DEFINITION This indicator is the Cell Quality Factor Absolute weighted by the cell traffic. Investigation shouldbe done in priority on the cell having a high rate of failures with high traffic (the traffic is the rate of

traffic handled by the cell over the total network traffic – traffic is TCH seizure attempts)

FORMULA CQFA * ((MC15a + MC15b + MC703)cell / (MC15a + MC15b + MC703)network)THRESHOLD N/ACOMMENTREF NAME QSCQRR UNIT %

Normalizing the previous Cell Quality Factor Absolute by the traffic of the cell will allow to compare the QoS of the cell between each other and raise the list of top worst cells candidate for analysis.

From B7, MC703 replaces MC16 of B6.






Network TCH Availability

Management indicator, maintenance oriented, assessingQuantity of stability problemsReaction time to problems

INDICATOR(G)

NETWORK (TCH) AVAILABILITY

DEFINITION Rate of TCHs able to carry traffic (upon the total number of traffic channels)FORMULA (Σcell (MC250) / #Available TCH)THRESHOLD < 95%COMMENT #Available TCH : according to channel configurationREF NAME TCAVAR UNIT %






Exercise

Time allowed:

15 minutes

Indicator value OK ? Impact1- SDCCH congestion 10% NOK difficulties to establish call2- Call drop 5%3- Call success 95%4- Efficiency of outgoing HO 91%5- Network TCH availability 94%6- TCH assignment failure 2,4 %7- Call drop 2,3 %8- SDCCH drop 2%9- HO cause distribution(ratio of better cell)

45%

10- Call success 88%11- SDCCH drop 1%





5 Traps and Restrictions of GlobalIndicators





5 Traps and Restrictions of Global Indicators

Objective

Beware of traps and restrictions about some global indicators

So as to be able to provide a reliable interpretation






Call Set-Up Success Rate / Call Drop Rate

CALL SETUP SUCCESS The radio link establishment failure is not taken into account, because:

most of failures during RLE are due to ghost RACHthe MS is attempting MAX_RETRANS+1 times before giving updifficult to assess subscriber's impact, anyhow very low

CALL DROPFor BSS, the last stage is considered as established, although it is not the cause from a user point of viewIf a TCH drop occurs during this phase

for the user, it is a setup failurefor the OMC-R indicators, counted as a call drop






Call Duration

IMPACT OF CALL DURATION

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






Mobility

IMPACT OF MOBILITYMost of drop problems are due to mobility

Usually 2/3 of calls are static (no HO will be done)For example, if 40 drops are observed for 1000 calls

40/1000 = 4% of global call dropbut most of call drops are generated by "moving calls"· 40/(1000*1/3) = 40/333 = 12 % of call drop rate for moving call· 0 % for static call

Typical trap when comparing drive tests results with OMC-R statistics






Exercise

Time allowed:

15 minutes

Case conclusion OK ? why

In 1 BSS, some transcoders are faulty: as soon as TCH are established on these TC, they are lost

The call setup success rate indicator will be increased due to this problem

In 1 network, drive tests are showing a general call drop of 7 %. OMC-R call drop indicator is giving 2,1 %

OMC-R indicator is erroneous (drive test is the reality)

In 1 network, global call setup success is 92 %

For moving call, call setup success will be about 76 %

In a pedestrian zone, 80 % of call are static measured call drop is 1,7 %

For taxi, call done in Taxi in this zone will be dropped at 5,1 %

call duration is more than average

global call drop: 2% for 1 call of 20 mns, risk of drop is 2 %

NOK






Steps to Take for Optimization

Flow Chart of Network Optimization

The Mobile Network is evaluated through Network Statistic (NPO), Drive Test (Agilent, TEMS, etc.) and Trouble Ticket (Alarms, etc.).Then the KPI Targets is set based on the consideration from all the data collected.

The Action Plan is proposed based on the studies of the network.

The Action Plan is based on Frequency, Cell Parameters/Configuration and Hardware Changes.After the Action plan is done, the network statistic and Drive Test is performed again to determine the KPI achieves the required Target. For the case where the KPI target is not achieved as requirements, the optimization work is repeated again until the achievement of KPI targets.

An advanced improvement plan may be achieved thanks to the help of Alcatel-Lucent support.





6 Global Indicators Interpretation






Exercise 1

Is this network OK?

Time allowed:

5 minutes

Name value

SDCCH congestion 1%SDCCH drop 3%TCH assignment failure rate 2%Call drop 1%Call setup success rate 96%Call success rate 94%Efficiency of outgoing HO 92%Efficiency of incoming HO 93%HO cause distribution better/level/quality 70/20/10Network TCH availability 98%

Name value







Exercise 2

Can one say that: all indicators are OK? the coverage of the network is 95%? the call success of all the cells is 95% (minimum)?

Time allowed:

5 minutes

Name value


Name value







Exercise 2

Results of field tests on a networkIs the network better if QSCDR = 2%?

Time allowed:

5 minutes

Name value

SDCCH congestionSDCCH dropTCH assignment failure rateCall drop 4.6%Call setup success rate 92%Call success rateEfficiency of outgoing HOEfficiency of incoming HOHO cause distribution better/level/qualityNetwork TCH availability

Name value

SDCCH congestionSDCCH dropTCH assignment failure rateCall drop 4.6%Call setup success rate 92%Call success rateEfficiency of outgoing HOEfficiency of incoming HOHO cause distribution better/level/qualityNetwork TCH availability





End of ModuleGlobal Indicators





Module 3Detailed Indicators









Blank Page




Document History





Module Objectives


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





Table of Contents


1 Indicator Reference Name 72 Indicators Classification 9





1 Indicator Reference Name





1 Indicator Reference Name

Description

Each QOS indicator has a unique REFERENCE NAME of 10 characters.

UnitFamily

Procedure Type JokerPrefix Sub-type

mandatory

optional





2 Indicators Classification






Main Categories

Classification

Control Channels

SCCP

TCH

SDCCH

Traffic load

Call statistics

RTCH

SDCCH

Global QoS

Couple of cells

SDCCH /TCHHO repartition

IntracellHO

Incoming HO

Outgoing HO

HO causes

Handoverstatistics

Resourceavailability

Multiband

Multilayer/MultibandNetwork

Concentric cells

Directed retry

Densificationtechniques

GSMindicators






SDCCH Traffic

Traffic Load and Traffic Model SDCCH traffic

Estab

SDCCH Traffic

TrafficMT

TrafficMO

Loc. Update

IMSI Detach

Sup. Service

Call

LU Follow on

SMS

CallRe-Estab

Other

MSPenetration Rate

TrafficDual Band

ResourceOccupancy

SDCCHErlang

SDCCH MeanHolding TimeGlobal

Traffic

GlobalRequests

TrafficModel

HandoverNormalAssignment

NormalAssignment

Handover

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 ModelTCH traffic RTCH Traffic

ResourceOccupancy

TCHErlang

Full RateErlang

Full RateAllocated

Full RateMean TCH

Time

Half RateErlang

Half RateAllocated

Half RateMean TCH

Time

Blocking Peak

Ratio ofHR Traffic

TCHMultibandOccupancy

Traffic Model

REQUESTSAssign / HO / DR

SUCCESSAssign/ HO/ DR

HO PER CALL

REQUESTSFR, DR, DR/EFR, AMR, DATA

Speech Version&

Channel Type

ALLOCATIONSFR, HR, EFR, AMR, DATA

SUCCESSAMR / TFO

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 ServiceSDCCH

SDCCH

EstablishedPhase

Drop Rate

Drop Radio Drop HO

Unsuccess

Congestion

Assignment Phase/

Handover

RadioFailure

BSS Failure

Access Reject

Dynamic Allocation

Drop BSS






QoS RTCH

GLOBAL Quality of service RTCH

DirectedRetry

RTCH

Unsuccess

Assignment Phase/

Handover

Global RadioCongestion Level

Congestion

RadioFailure

BSSFailure

EstablishedPhase

Drop rate

Drop Radio

Drop BSS

Drop HO

Preemption

PreemptionPhase

PCI =1 PVI =1

Requests

Allocationwith / withoutPreemption

Failure

Success

Success

QueuingPhase

Queue Length

AssignQueuing Fail

AssignQueued

& Reject

QueuedSuccess

Queue Full

HigherPriority

Timeout

AssignQueued

NormalAssign.






QoS Call Statistics

GLOBAL Quality of serviceCall statistics Call Statistics

Call Success

Call SetupSuccess Rate

CallSuccess Rate

Cell QualityFactor Absolute

Cell QualityFactor Relative

Call Drop

Call Drop Rate

Drop Radio Drop BSSDrop HO

Transcoder Failure

BSS Internal Failure

Call DropEnd User Rate

Preemption






Handover Causes

Handover STATISTICSHandover causes

Handover causes

HO causes

All HO

cause distribution

Outgoing HO Incoming HO

HO standardcause

distribution

HO cause category

distribution

HO causes per Adjacency

HO cause category

distribution

Fast traffic HO taken into account type of counter for dual band HO






Outgoing Handovers

Handover STATISTICSOutgoing handovers

Failure With Reversion

Call Drop Rate

Efficiency

Preparation Success Rate

Intra-BSC


Call Drop Rate

Efficiency


External

Call Drop Rate

Efficiency

Success Rate

Intra-BSC & External

Outgoing HO

LAPD counter to analyze the cause of delay in HO procedures






Incoming Handovers

Handover STATISTICSIncoming handovers

Failure BSS

Failure Radio

Congestion

Efficiency

Intra-BSC

Failure BSS

Failure Radio

Failure No CIC

Congestion

Efficiency

External

Efficiency

Intra-BSC & External

Incoming HO

Incoming external HO 3G - > 2G

Incoming external HO 2G - > 2G only






Incoming Handovers [cont.]

More counters for UMTS to GSM handover monitoring. The new counters were introduced in the MC922 family:

MC922e (type110): NB_INC_EXT_TCH_3G_2G_HO_EMERGENCY_REQ that indicates the number 3G to 2G external inter-cell TCH (in HR or FR) handover requests, with emergency cause.MC922f (type 110): NB_INC_EXT_TCH_3G_2G_HO_REQ that indicates the number of 3G to 2G external inter-cell TCH (in HR or FR) handover requests. This counter differs from MC922d by the fact it just counts TCH handovers.MC922g (type 110): NB_INC_EXT_TCH_3G_2G_HO_PREP_FAIL_3GCONG that indicates the number of 3G to 2G handover failures in preparation phase due to 3G high load in target cell.MC922h (type 110): TIME_3G_HOReject_HL that indicates the cumulative time (in seconds) during which the cell is in 3G high load state.






Intracell Handovers

Handover STATISTICSIntracell handovers

New B9 counters: HO Cause 30NB_TCH_HO_REQ_30_ReturnCSZone=MC480 (Type 110)NB_TCH_HO_ATPT_30_ReturnCSZone=MC481 (Type 110)

CDR Radio CDR BSS


Failure BSS

Call Drop Rate

Congestion

Efficiency

Intracell HO






Handover Statistics per Couple of Cells

Handover STATISTICSHandover statistics per couple of cell

HO Success Distribution

Success Rate

Efficiency


HO statisticsper Couple of Cell





End of ModuleDetailed Indicators





Module 4Handover Indicators









Blank Page




Document History





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





Table of Contents


1 Intra-Cell Handover Indicators per Cell 72 Internal Handover Indicators per Cell 173 External Handover Indicators per Cell 314 Handover Indicators per Couple of Cells 46





1 Intra-Cell Handover Indicators per Cell






Handover Types

HO FAIL. CASES > HO ReminderIntra-Cell: Handover between two TCHs of the same cellInternal

between two cells of the same BSCalso called intra BSCand not using the forced external handover mode

Externalbetween two cells of different BSCsalso called inter BSCor between two cells of the same BSC when using the forced external handover mode

TCH/(SDCCH) HandoverSynchronous

between 2 cellssharing the same clockscollocatedusually 2 sectors of the same BTS

tunable at OMC-R level

Asynchronousnot synchronous for any reasonno dedicated monitoring for synchronous/asynchronous HO

Incomingas considering the target cell

Outgoingas considering the serving cell






Intracell HO - Success

HO FAIL. CASES > intracell HO > successful caseMS BTS BSC MSC

MEAS REPORT-----------------------------> MEASUREMENT RESULT

--------------------------------------------------------------> MC870PHYSICAL CONTEXT REQUEST (old channel)

<--------------------------------------------------------------PHYSICAL CONTEXT CONFIRM (old channel)

-------------------------------------------------------------->CHANNEL ACTIVATION (new channel)

<--------------------------------------------------------------CHANNEL ACTIVATION ACK (new channel)

-------------------------------------------------------------->ASSIGNMENT CMD ASSIGNMENT COMMAND (old channel) MC871

<----------------------------- <-------------------------------------------------------------- start T3107SABM

-----------------------------> ESTABLISH INDICATION (new channel)UA -------------------------------------------------------------->

<-----------------------------ASSIGNMENT CMP ASSIGNMENT COMPLET(new channel)

-----------------------------> --------------------------------------------------------------> stop T3107MC662

HANDOVERPERFORMED

RF CHANNEL RELEASE (old channel)

RF CHANNEL RELEASE ACK (old channel)<--------------------------------------------------------------

-------------------------------------------------------------->

------------------------------------->

MFS

------------------>BSC Shared DTM Information Indication

B10

Case of a DTM capable MS in dedicated mode

New B10

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

BinhPT

Typewriter

HandOver Counter Internal External Intra cell TCH (T110-T28) Outgoing Incoming Out In REQUEST TCH+ SD MC870 MC870-C360 MC655A MC830 MC645A MC820 congestion Radio MC561 MC551 MC541A congestion A if MC41B ASSIG ( Attempt) TCH+SD MC871 MC660 MC831 MC650 MC821 reversion to old Ch. MC667 MC657 MC647 drop ratio (MC621 - All ) MC663 MC658 MC648 Incoming HO failed MC653 MC643 OCCUPY TCH+SD MC662 MC656 MC652 MC646 MC642

BinhPT

Typewriter

MC621: All drop of Inter and Intra

BinhPT

Typewriter

Incoming HO - Check HO congestion Outgoing HO - CHeck HO fail to drop or reverse

BinhPT

Typewriter

TCH Cong. ( No H.O): Normal Cong. - add TCH - Queue - More outgoing H.O

BinhPT

Typewriter

TCH Cong.( H.O ) ( due to IN. HO) - Less Incoming H.O - add TCH






Intracell HO – Success Case of a MS in DTM Mode

HO FAIL. CASES > intracell HO > successful case

MS BTS BSC MSC


--------------------------------------------------------------> MC870PHYSICAL CONTEXT REQUEST (old channel)

<--------------------------------------------------------------PHYSICAL CONTEXT CONFIRM (old channel)

-------------------------------------------------------------->CHANNEL ACTIVATION (new channel)

<--------------------------------------------------------------CHANNEL ACTIVATION ACK (new channel)

-------------------------------------------------------------->ASSIGNMENT CMD ASSIGNMENT COMMAND (old channel) MC871

<----------------------------- <-------------------------------------------------------------- start T3107SABM

-----------------------------> ESTABLISH INDICATION (new channel)UA -------------------------------------------------------------->

<-----------------------------ASSIGNMENT CMP ASSIGNMENT COMPLET(new channel)

-----------------------------> --------------------------------------------------------------> stop T3107MC662

HANDOVERPERFORMED

RF CHANNEL RELEASE (old channel)

RF CHANNEL RELEASE ACK (old channel)<--------------------------------------------------------------

-------------------------------------------------------------->

------------------------------------->

MFS

------------------>BSC Shared DTM Information Indication

B10

Case of a DTM capable MS in DTM mode

<-----------------------MFS Shared DTM Information Indication

------------------>MFS Shared DTM Information Indication ACK

New B10


The T3107 timer is also used as the guard timer of the channel change procedure during an intra cell handover. The dDefault 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

BinhPT

Typewriter

HO Congestion - TYPE 180 or all cells Reduce INC HO or add TCH need to find MAX INC REQ cells






Intracell HO - Failures

HO FAIL. CASES > intracell HO Failures

Handover Preparation: congestion BSS problem (no specific counter)

Handover Execution: reversion to old channeldrop radioBSS problem (no specific counter)






Intracell HO - Congestion

HO FAIL. CASES > intracell HO Failure: Congestion

MC561TCH+MC101SDCCHMS Serving BTS Serving BSC MSC


--------------------------------------------------------------> MC870No free TCH

MC561

From B7, MC561 replaces MC61of B6.

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






Intracell HO - Radio Failure ROC

HO FAIL. CASES > intracell HO failure: Reversion Old ChannelServing Serving

MS BTS BSC MSCMC871

ASSIGNMENT CMD ASSIGNMENT COMMAND (old channel)<----------------------------- <----------------------------------------------------------------- start T3107 (= T10)start T200

SABM (new channel)-----------------------------> ESTABLISH INDICATION (new channel)

----------------------------------------------------------------->UA (new channel)

X- - - - - --------------------SABM (new channel)

----------------------------->UA (new channel)

X- - - - - --------------------

SABM (old channel)-----------------------------> ESTABLISH INDICATION (old channel)

UA (old channel) -----------------------------------------------------------------><-----------------------------ASSIGNMENT FAIL ASSIGNMENT FAILURE-----------------------------> -----------------------------------------------------------------> stop T3107

MC667PHYSICAL CONTEXT REQUEST (new channel)

<-----------------------------------------------------------------PHYSICAL CONTEXT CONFIRM (new channel)

----------------------------------------------------------------->RF CHANNEL RELEASE (new channel)

<-----------------------------------------------------------------RF CHANNEL RELEASE ACK (new channel)

----------------------------------------------------------------->






Intracell HO - Radio Failure Drop

HO FAIL. CASES > intracell HO failure: Radio drop

MC663=C63TCH+C103SDCCHServing Serving

MS BTS BSC MSCMC871

ASSIGNMENT CMD ASSIGNMENT COMMAND (old channel)<----------------------------- <----------------------------------------------------------------- start T3107 (= T10)

MC663Release of old and new channels T3107 expiry






Intracell HO - BSS Problem

HO FAIL. CASES > intracell HO failure: BSS drop

no specific counter

Serving ServingMS BTS BSC MSC

MC871ASSIGNMENT CMD ASSIGNMENT COMMAND (old channel)<----------------------------- <----------------------------------------------------------------- start T3107 (= T10)

--------------------------------------- >CLEAR REQUEST

O&M interventionRadio interface failure

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






Intracell HO - Counters

HO FAIL. CASES > intracell HO counters

Request MC870

Congestion MC561+MC101BSS Pb MC870-MC871-(MC561+MC101)

Attempt MC871

Reversion old channel MC667Drop radio MC663BSS Pb MC871-MC662-MC667-MC663

Success MC662

Preparation

Execution

INTRACELL Handover

REQUEST

CONGESTION

ATTEMPT

REVERSION OLD CHANNEL

DROP RADIO

BSS PB

SUCCESS

BSS PB

Preparation Failure

Execution Failure





2 Internal Handover Indicators per Cell






Internal HO - Success

HO FAIL. CASES > internal HO > success caseThe same inter-cell handover procedure leads to an incrementation of two sets of counters:

incoming HO counters for the target cell: MC830, MC831, MC652, etc.

outgoing HO counters for the serving cell: MC655A, MC660, MC656, etc.

In HO_PERFORMED MESSAGE>Target cell (CI,LAC)>"cause" of HO

MS serving cell target cell BSC MSCMEAS REP

-----------------------> MEASUREMENT RESULT------------------------------------------------------------------------>MC830, MC655A

CHANNEL ACTIVATION<----------------------------------

CHAN ACTIV ACK---------------------------------->

HO CMD HANDOVER COMMAND<----------------------- <------------------------------------------------------------------------start T3103

MC831, MC660start T3124

HANDOVER ACCESS------------------------------------------------------------->-------------------------------------------------------------> HO DETECTION

PHYSICAL INFORMATION ----------------------------------><------------------------------------------------------------- start T3105stop T3124start T200------------------------ SABM ---------------------------> stop T3105<-------------------------- UA ----------------------------- ESTABLISH INDICATIONstop T200 ---------------------------------->

HANDOVER COMPLETE HO CMP stop T3103-------------------------------------------------------------> ----------------------------------> HO PERFORMED

Release of old TCH MC652, MC656

--------------->BSC Shared DTM Information Indication (old cell)

----------------------------->

MFS

<-------------------------------------------------------------DTM Information (new cell)

BSC Shared DTM Information Indication (new cell) --------------->

B10


New B10


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.






Internal HO – Success Case of an MS in DTM Mode

HO FAIL. CASES > internal HO > success caseMS serving cell target cell BSC MSC

MEAS REP-----------------------> MEASUREMENT RESULT

------------------------------------------------------------------------>MC830, MC655ACHANNEL ACTIVATION

<----------------------------------CHAN ACTIV ACK

---------------------------------->HO CMD HANDOVER COMMAND

<----------------------- <------------------------------------------------------------------------start T3103MC831, MC660

HANDOVER COMPLETE HO CMP stop T3103-------------------------------------------------------------> ---------------------------------->HO PERFORMED

MC652, MC656----------------------------->

MFS

B10

…………….

SGSN

DTM Information DTM Information

MFS Shared DTM Info Ind

MFS Shared DTM Info Ind ACK

BSC Shared DTM Info Ind (old cell)

BSC Shared DTM Info Ind (new cell)

Release of old TCH

------------------------------------------------------------->GPRS Information (cell update)

------------------------------------------------->

BSCGP DTM GPRS Information UL (cell update) Cell update

Flush LL

Flush LL ack

New B10


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.






Incoming Internal HO - Failures

HO FAIL. CASES > Incoming internal HO failures:

Handover procedure from the target cell point of view

Handover Preparation: congestion: no RTCH available in the target cell

does not concern the outgoing side (serving cell point of view)BSS problem (no specific counter)

Handover Execution: radio problem: the MS fails to access the new channel

the reversion/drop discrimination concerns only the serving cellBSS problem (no specific counter)






Incoming Internal HO - Congestion

HO FAIL. CASES > Incoming internal HO fail: congestion

MC551TCH+MC91SDCCH

MS Serving Cell Serving BSC MSC


--------------------------------------------------------------> MC830No free TCH

MC551

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

HO FAIL. CASES > Incoming internal HO fail: MS access problem


-----------------------> MEASUREMENT RESULT------------------------------------------------------------------------>


CHANNEL ACTIV ACK---------------------------------->

HO CMD HANDOVER COMMAND<----------------------- <------------------------------------------------------------------------ start T3103

MC660SABM

-----------x T3103 expiry MC653

MS Serving cell Target Cell BSC


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

Release of new channel

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

HO FAIL. CASES > Incoming internal HO counters

Request MC830


Attempt MC831

Radio (MS access problem) MC653BSS Pb MC831-MC652-MC653

Success MC652

Execution

Preparation

INCOMING INTERNAL Handover

REQUEST

CONGESTION

ATTEMPT

MS ACCESS PB

BSS PB

SUCCESS

BSS PB

Preparation Failure

Execution Failure






Incoming Internal HO - Indicators

HO FAIL. CASES > Incoming internal HO indicators

HOIBFLBN

HOIBFLRN

HOIBCGN

HOIBSUN

HOIBFLR

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:

Handover Statistics INDICATORS > Incoming handover > Incoming Intra BSC

HOIBEFR: efficiency of the incoming internal HO execution

HOIBCGR: rate of incoming internal HO failures due to congestion

HOIBPFR: rate of incoming internal HO failures due to BSS during the preparation phase

HOIBFLRR: rate of incoming internal HO failures due to radio problems

HOIBFLBR: rate of incoming internal HO failures due to BSS during the execution phase






Outgoing Internal HO - Failures

HO FAIL. CASES > Outgoing internal HO failures

Handover procedure from the serving cell point of view

Handover Preparation: congestion on the target cell (no specific counter on the serving cell)BSS problem (no specific counter)

Handover Execution: radio problem: the MS reverts to the old channelradio problem: the MS dropsBSS problem (no specific counter)






Outgoing Internal HO - Radio Failure ROC

HO FAIL. CASES > Outgoing internal HO fail: Reversion old channelMS Serving cell Target Cell BSC


HANDOVER ACCESS MC660------------------------------------------------------------->-------------------------------------------------------------> HO DETECTION



UA ----------------------------------><------------------------------------------------------------- stop T3105



UA ------------------------------------------------------------------------><-----------------------

HO FAILURE HANDOVER FAILURE-----------------------> ------------------------------------------------------------------------> MC657







Outgoing Internal HO - Radio Failure Drop

HO FAIL. CASES > Outgoing internal HO fail: drop

clear_request: ask the MSC to release the connectionIn case of call drop due to HO, the cause is "radio interface message failure" (for Alcatel-Lucent)


-----------------------> MEASUREMENT RESULT------------------------------------------------------------------------> MC655A


CHAN ACTIV ACK---------------------------------->


MC660SABM

----------xT3103 expiryMC658

Clear_request------------------------>

Clear_commandRelease of old and new TCH <------------------------






Outgoing Internal HO - Counters

HO FAIL. CASES > Outgoing internal HO counters

Preparation Request MC655A

Any preparation failure MC655A-MC660

Attempt MC660


Success MC656

Execution

OUTGOING INTERNAL Handover

REQUEST

CONGESTION

ATTEMPT


DROP RADIO

BSS PB

SUCCESS

BSS PB

Preparation Failure

Execution Failure






Outgoing Internal HO - Indicators

HO FAIL. CASES > Outgoing internal HO indicators

HOOBSUN

HOOBCDRN

HOOBCDBN

HOOBOCN

HOOBCDR

HOOBOCR

SUCCESS

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: Handover Statistics INDICATORS > Outgoing handover > Outgoing Intra BSC

HOOBRQR: efficiency of the outgoing internal HO preparation

HOOBEFR: efficiency of the outgoing internal HO execution

HOOBOCR: rate of outgoing internal HO failures due to radio problems with Reversion Old Channel

HOOBCDRR: rate of outgoing internal HO failures due to radio problems with drop

HOOBCDR: 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 reversion2) One case of Internal handover success

Identify the target cellIdentify the serving cell (in CR for call establishment)

3) One case of Internal handover failure with reversion4) One case of Internal handover failure without reversion

Find in trace 7:1) The identity of the new TCH assigned while MS in DTM mode

B10

New B10

Time allowed:

15 minutes





3 External Handover Indicators per Cell






External HO - Success

HO FAIL. CASES > External HO > successful case

MS serving_cell BSC MSC BSC target_cell MS- MEAS_REPORT ->

------- MEAS_RESULT -------->MC645A ------ HO_REQUIRED ---------->

----------CR (HO_REQUEST) -----> MC820<--------- CC ------------------------ ---- CHANNEL_ACTIVATION ------>

<- CHANNEL_ACT_ACK-------------<----- HO_REQUEST_ACK -------- Start T9113

(HO_COMMAND) MC821<------------------------- HO_COMMAND ------------------------------------------------------ <---- HO_ACCESS -----

MC650 Start T8 <---- HO_ACCESS -----<------ HO_DETECTION--------------

<-- HO_DETECTION -------------- --- PHYSICAL_INFO -->

<--- SABM ---------------<----- ESTABLISH_INDICATION ---- ----- UA -------------->

<----------- HO_COMPLETE ----------------------------------------<--- HO_COMPLETE --------------- Stop T9113

<---- CLEAR_COMMAND ------

MC642

MC646 Cause : HO_SUCCESSFULRelease of TCH Stop T8

MC462A

MC462B

MC462C

MC463A

MC463B

MC463C

MFS

BSC shared DTM info indication

DTM informationBSC shared DTM info indication

B10


New B10

Both SDCCH and TCH are counted together.From B7, MC645A replaces MC645 of B6.MC645a is only counting HANDOVER REQUIRED messages that are linked to a handover trial and not those that are linked to the update of the candidate cell list for handover / directed retry. This is leading to a more accurate computation of the External outgoing HO success rate.Only Outgoing inter PLMN HO is allowed.6 counters provide information for "Inter-PLMN HO" (Incoming and Outgoing) (From B8)

MC462a (equivalent of MC645A for intra PLMN external HO)Number of inter-PLMN TCH outgoing handovers or directed retry requests: HANDOVER REQUIRED sent to the MSC for an external TCH HO or an external DR triggered towards a cell belonging to a PLMN different from the PLMN of the serving cell.

MC462b (equivalent of MC650 for intra PLMN external HO)Number of inter-PLMN TCH outgoing handovers or directed retry attempts: HANDOVER COMMAND sent to the MS on Abis for an external TCH HO or an external DR triggered towards a cell belonging to a PLMN different from the PLMN of the serving cell.

MC462c (equivalent of MC646 for intra PLMN external HO)Number of inter-PLMN TCH outgoing handovers or directed retry successes: CLEAR COMMAND with Cause "Handover successful" received from the MSC for an external TCH HO or an external DR triggered towards a cell belonging to a PLMN different from the PLMN of the serving cell.

MC463a (equivalent of MC820 for intra PLMN external HO)Number of inter-PLMN TCH incoming handovers or directed retry requests: HANDOVER REQUEST received from the MSC for an external TCH HO or an external DR triggered towards the target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.

MC463b (equivalent of MC821 for intra PLMN external HO)Number of inter-PLMN TCH incoming handovers or directed retry attempts: HANDOVER REQUEST ACK sent by the target BSC containing the HANDOVER COMMAND for an external TCH HO or an external DR triggered towards the target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.

MC463c (equivalent of MC642 for intra PLMN external HO)Number of inter-PLMN TCH incoming handovers or directed retry successes: HANDOVER COMPLETE received from the MS on Abis for an external TCH HO or an external DR triggered towards the target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.Note than all other (previous) counters related to HO continue to be based on Intra PLMN only.






External HO – Success Case of an MS in DTM Mode

HO FAIL. CASES > External HO > successful case


------- MEAS_RESULT -------->MC645A ------ HO_REQUIRED ---------->

----------CR (HO_REQUEST) -----> MC820<--------- CC ------------------------ ---- CHANNEL_ACTIVATION ------>

<- CHANNEL_ACT_ACK-------------<----- HO_REQUEST_ACK -------- Start T9113

(HO_COMMAND) MC821<------------------------- HO_COMMAND ------------------------------------------------------ <---- HO_ACCESS -----

MC650 Start T8 <---- HO_ACCESS -----<------ HO_DETECTION--------------

<-- HO_DETECTION -------------- --- PHYSICAL_INFO -->



<---- CLEAR_COMMAND ------

MC642

MC646Cause : HO_SUCCESSFUL

Release of TCH Stop T8

MC462A

MC462B

MC462C

MC463A

MC463B

MC463C

MFS SGSN

BSC shared DTM info indication

DTM informationBSC shared DTM info indication

B10

MFS shared DTM info indication

MFS shared DTM info indication ack

GPRS Information (cell update) BSCGP DTM GPRS Information UL (cell update)

Cell update Flush LL Flush LL ack

New B10

Both SDCCH and TCH are counted together.From B7, MC645A replaces MC645 of B6.MC645a is only counting HANDOVER REQUIRED messages that are linked to a handover trial and not those that are linked to the update of the candidate cell list for handover / directed retry. This is leading to a more accurate computation of the External outgoing HO success rate.Only Outgoing inter PLMN HO is allowed.6 counters provide information for "Inter-PLMN HO" (Incoming and Outgoing) (From B8)

MC462a (equivalent of MC645A for intra PLMN external HO)Number of inter-PLMN TCH outgoing handovers or directed retry requests: HANDOVER REQUIRED sent to the MSC for an external TCH HO or an external DR triggered towards a cell belonging to a PLMN different from the PLMN of the serving cell.

MC462b (equivalent of MC650 for intra PLMN external HO)Number of inter-PLMN TCH outgoing handovers or directed retry attempts: HANDOVER COMMAND sent to the MS on Abis for an external TCH HO or an external DR triggered towards a cell belonging to a PLMN different from the PLMN of the serving cell.

MC462c (equivalent of MC646 for intra PLMN external HO)Number of inter-PLMN TCH outgoing handovers or directed retry successes: CLEAR COMMAND with Cause "Handover successful" received from the MSC for an external TCH HO or an external DR triggered towards a cell belonging to a PLMN different from the PLMN of the serving cell.

MC463a (equivalent of MC820 for intra PLMN external HO)Number of inter-PLMN TCH incoming handovers or directed retry requests: HANDOVER REQUEST received from the MSC for an external TCH HO or an external DR triggered towards the target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.

MC463b (equivalent of MC821 for intra PLMN external HO)Number of inter-PLMN TCH incoming handovers or directed retry attempts: HANDOVER REQUEST ACK sent by the target BSC containing the HANDOVER COMMAND for an external TCH HO or an external DR triggered towards the target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.

MC463c (equivalent of MC642 for intra PLMN external HO)Number of inter-PLMN TCH incoming handovers or directed retry successes: HANDOVER COMPLETE received from the MS on Abis for an external TCH HO or an external DR triggered towards the target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.Note than all other (previous) counters related to HO continue to be based on Intra PLMN only.






External HO - Failures

HO FAIL. CASES > Incoming external HO failures

Handover procedure from the target cell point of view

Handover Preparation: congestion: no RTCH available in the target cell OR no TTCH available on the A interface


Handover Execution: radio problem: the MS fails to access the new channel







Incoming External HO - RTCH Congestion

HO FAIL. CASES > Incoming external HO fail: Air/Abis cong.MC541ATCH+MC81SDCCH


------- MEAS_RESULT -------->MC645A ------ HO_REQUIRED ------->

----------CR (HO_REQUEST) -----> MC820

<----- HO_FAILURE --------------- MC541A( <-HO_REQUIRED_REJECT-) Cause: no radio resource available

From B7, MC541A replaces MC41A of B6.

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






Incoming External HO - TTCH Congestion

HO FAIL. CASES > Incoming external HO fail: A int. cong.

MC41B


------- MEAS_RESULT -------->MC645A ------ HO_REQUIRED ------->

----------CR (HO_REQUEST) -----> MC820

<----- HO_FAILURE --------------- MC41BCause: terrestrial circuit already allocatedRequested terrestrial resource unaivalableBSS not equiopoed

( <-HO_REQUIRED_REJECT-)






Incoming External HO - Radio Failure

HO FAIL. CASES > Incoming external HO fail: MS access problem


------- MEAS_RESULT -------->MC645A ---- HO_REQUIRED ------->

----------CR (HO_REQUEST) -------------------> MC820<-------- CC --------------------------------------- - CHANNEL_ACT ---------->

<--- CHA_ACT_ACK --------Start T9113

<----- HO_REQUEST_ACK----------------------- Start T9113<-------------------------- HO_COMMAND ------------------------------------------------ HO-COMMAND) included° MC821

Start T8 X --- HO_ACCESS -----X ---- HO_ACCESS -----

----- SABM --- X----- SABM --- X

----- SABM --- X T9113 expiryMC643

Release of connection



----------CR (HO_REQUEST) -------------------> MC820<-------- CC --------------------------------------- - CHANNEL_ACT ---------->

<--- CHA_ACT_ACK --------<----- HO_REQUEST_ACK----------------------- Start T9113 (HO-COMMAND) included MC821

<-------------------------- HO_COMMAND ------------------------------------------------Start T8 X --- HO_ACCESS -----

X ---- HO_ACCESS ---------- SABM --------><--- UA ------------- -- ESTABLISH_INDICATION->

----- HO_FAILURE (reversion to old channel) ------------------------------------------>----- CLEAR_COMMAND ----------------------> MC643Radio interface fail : Reversion to old channel


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

HO FAIL. CASES > Incoming external HO countersInter PLMN HO Intra PLMN HO

Request MC820


Attempt MC821

Radio (MS access problem) MC643BSS Pb MC821-MC642-MC643

Success MC642

Execution

Preparation

INCOMING EXTERNAL Handover

REQUEST

CONGESTION

ATTEMPT

MS ACCESS PB

BSS PB

SUCCESS

BSS PB

Preparation Failure

Execution Failure

ATTEMPT SUCCESS

REQUEST

RATIO






Incoming External HO - Indicators

HO FAIL. CASES > Incoming external HO indicators

HOIMFLBN

HOIMFLRN

HOIMCGN

HOIMSUN

HOIMFLR


Handover Statistics INDICATORS > Incoming handover > Incoming Inter BSC

HOIMEFR: efficiency of the incoming external HO execution

HOIMCGR: rate of incoming external HO failures due to radio congestion (Air or Abis TCH)

HOIMAMR: rate of incoming external HO failures due to CIC congestion (A TCH)

HOIMPFR: rate of incoming external HO failures due to BSS during the preparation phase

HOIMFLRR: rate of incoming external HO failures due to radio problems

HOIMFLBR: 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

HO FAIL. CASES > Outgoing external HO failures

Handover procedure from the serving cell point of view

Handover Preparation: congestion on the target cell (no specific counter on the serving cell)BSS problem (no specific counter)

Handover Execution: radio problem: the MS reverts to the old channelradio problem: the MS dropsBSS problem (no specific counter)






Outgoing External HO - Radio Failure ROC

HO FAIL. CASES > Outgoing external HO fail: reversion old channel



----------CR (HO_REQUEST) -------------------><-------- CC --------------------------------------- - CHANNEL_ACT ---------->

<--- CHA_ACT_ACK --------<----- HO_REQUEST_ACK----------------------- Start T9113 (HO-COMMAND) included

<-------------------------- HO_COMMAND ------------------------------------------------Start T8 X --- HO_ACCESS -----MC650 X ---- HO_ACCESS -----

----- SABM --------><--- UA ------------- -- ESTABLISH_INDICATION->

----- HO_FAILURE (reversion to old channel) ------------------------------------------>MC647 ----- CLEAR_COMMAND ---------------------->

Radio interface fail : Reversion to old channel Release of connection






Outgoing External HO - Radio Failure Drop

HO FAIL. CASES > Outgoing external HO fail: drop



----------CR (HO_REQUEST) -------------------><-------- CC --------------------------------------- - CHANNEL_ACT ---------->

<--- CHA_ACT_ACK --------<----- HO_REQUEST_ACK----------------------- Start T9113 (HO-COMMAND) included

<-------------------------- HO_COMMAND ------------------------------------------------Start T8 X --- HO_ACCESS -----MC650 X ---- HO_ACCESS -----

----- SABM --- X----- SABM --- X

----- SABM --- X

T8 expiry ----- CLEAR_REQUEST ->MC648 Radio interface message fail Release of connection






Outgoing External HO - Counters

HO FAIL. CASES > Outgoing external HO countersInter PLMN HO Intra PLMN HO

Preparation Request MC645A

Any preparation failure MC645A-MC650

Attempt MC650


Success MC646

Execution

OUTGOING EXTERNAL Handover

REQUEST

CONGESTION

ATTEMPT


DROP RADIO

BSS PB

SUCCESS

BSS PB

Preparation Failure

Execution Failure

ATTEMPT SUCCESS

REQUEST

RATIO






Outgoing External HO - Indicators

HO FAIL. CASES > Outgoing external HO indicators

HOOMSUN

HOOMCDRN

HOOMCDBN

HOOMOCN

HOOMCDR

HOOMOCR

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

Handover Statistics INDICATORS > Outgoing handover > Outgoing Inter BSC

HOOMRQR: efficiency of the outgoing external HO preparation

HOOMEFR: efficiency of the outgoing external HO execution

HOOMOCR: rate of outgoing external HO failures due to radio problems with Reversion Old Channel

HOOMCDRR: rate of outgoing external HO failures due to radio problems with drop

HOOMCDR: 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) 1 incoming external HO success2) 1 outgoing external HO success3) 1 incoming external HO failure4) 1 outgoing external HO failure

In trace 11, extract (if available): 1) 1 intra BSC inter-cell HO success while in DTM

B10

New B10

Time allowed:

15 minutes





4 Handover Indicators per Couple of Cells






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 successfullyperformed to cell T from cell S

both internal and external inter cell handovers are countedboth SDCCH and TCH handovers are counted

a

e

d

c

b

f

C40i(f,d)

C40i(a,b)C40i(c,b)

C40i(c,d)

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

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 efficiency of incoming handovers to cell T from cell SHOOASUR = C402(S,T) / C400(S,T)Efficiency of the incoming handover preparation to cell T from cell SHOOACAR = C401(S,T) / C400(S,T)Efficiency of the incoming handover execution to cell T from cell SHOOAEFR = C402(S,T) / C401(S,T)

n

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 Counters

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)

Counters for each (Serving,Target x) adjacency: - C720(S,Tx): Outgoing handovers attempted from cell S to cell Tx- C721(S,Tx): Outgoing handovers successfullyperformed from cell S to cell Tx- C722(S,Tx): Outgoing handovers failed from cell S to cell Tx with Reversion Old Channel- C723(S,Tx): Outgoing handovers failed from cell S to cell Tx with drop

Target a

Te

Serving

Tc

Tb

Tf

C72i(S,Te)

C72i(S,Tc)

Other counters are provided:

C724(S,Tx): Outgoing handovers attempted from S to Tx for an emergency cause.

C725(S,Tx): Outgoing handovers attempted from S to Tx for a better cell cause.

C727(S,Tx): Outgoing handovers attempted from S to Tx for a traffic cause.

C728(S,Tx): Outgoing handovers attempted from S to Tx for a forced directed retry cause.

Previously the set of Type 26 counters could be retrieved for only one cell per BSS at once.

40 cells at the same time since B8.






Type 26 Indicators

The following indicators can be computed from PM Type 26 counters (40 cells since B8) in order to ease the diagnosis of the bad outgoing handover performance of a cell:

Efficiency of the outgoing handover execution from cell S to cell TxHOOXSUR = C721(S,Tx) / C720(S,Tx)

Rate of outgoing ho execution failures due to radio problems from S to Tx with drop

HOOXCDRR = C723(S,Tx) / C720(S,Tx)Rate of outgoing ho execution failures due to radio problems from S to Tx with Reversion Old Channel

HOOXOCR = C722(S,Tx) / C720(S,Tx)Rate of outgoing ho execution failures due to BSS problems from S to Tx

HOOXCDBR = [C720(S,Tx)-C721(S,Tx)-C722(S,Tx)-C723(S,Tx)] / C720(S,Tx)

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: Handover Statistics > HO Statistics per couple of cells > Indicators with counter type 26.

From B8, these type 26 counters are available for several cells at once (40 cells).






Type 27 Counters

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.

Counters for each (Serving,Target x) adjacency: - C730(Sx,T): Incoming handovers attempted to cell T from cell Sx- C731(Sx,T): Incoming handovers successfullyperformed to cell T from cell Sx- C733(S,Tx): Incoming handovers failed due to MS radio access problems to cell T from cell Sx

Serving a

Se

Target

Sc

Sb

Sf

C73i(Se,T)

C73i(Sc,T)

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 SxHOIXSUR = C731(Sx,T) / C730(Sx,T)Rate of incoming ho execution failures due to MS radio access problems to cell T from cell SxHOIXCDRR = C733(Sx,T) / C730(Sx,T)Rate of incoming ho execution failures due to BSS problems to cell T from cell SxHOIXCDBR= [C730(Sx,T)-C731(Sx,T)-C733(Sx,T)] / C730(Sx,T)

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:Handover Statistics > HO Statistics per couple of cells > Indicators with counter type 27





Summary for handover failure analysis using Type 180, 26 and 27


Usage of Indicators per Couple of Cells

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:Handover Statistics > HO Statistics per couple of cells > Indicators with counter type 27





End of ModuleHandover Indicators





Module 5Directed Retry Indicators









Blank Page




Document History





Module Objectives


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





Table of Contents


1 Directed Retry Definition 7





1 Directed Retry Definition






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…

The queuing of TCH requests is also performed for incoming external TCH handovers but not for incoming internal TCH handovers.






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 cellthe number of free TCHs in this neighboring cell is sufficient






Directed Retry Rules

DR FAIL. CASES > DR ReminderDR as an SDCCH to TCH handover

can beInternal

between two cells of the same BSCalso called intra BSC

Externalbetween two cells of different BSCsalso called inter BSC

Incomingas considering the target cell

Outgoingas considering the serving cell

Synchronousbetween 2 cellssharing the same clockscollocatedusually 2 sectors of the same BTS

tunable at OMC-R level

Asynchronousnot synchronous for any reasonno dedicated monitoring for synchronous/asynchronous HO

ANNEX 3

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.





End of ModuleDirected Retry Indicators





Module 6Radio Measurement Statistics Indicators









Blank Page




Document History





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





Table of Contents


1 Radio Measurement Statistics Objectives 72 RMS Implementation in the BSS 103 RMS Data 164 Call Quality Statistics per TRX 18

4.1 Generalities 194.2 Call Quality Parameters 224.2 Call Quality Counters 24

5 Radio Quality Statistics per TRX 285.1 Generalities 295.2 Radio Quality Parameters 325.3 Radio Quality Counters 35

6 C/I Statistics 496.1 C/I Generalities 506.2 C/I Parameters 516.3 C/I Counters 52

7 Call Drop with Specific Radio Causes 547.1 Generalities 557.2 Thresholds for Detection 567.3 Counters 57

8 RMS Indicators Usage 588.1 Suspecting a Voice Quality Problem 598.2 Suspecting a Cell Coverage Problem 608.3 Suspecting a Cell Interference Problem 64

9 Additional Information 69





1 Radio Measurement Statistics Objectives






RMS Objectives

Assess the quality of cell coverageAssess the radio link quality of a TRX / a cellAssess Carrier/Interference ratio of a TRX / a cellEstimate the voice quality of a TRX / a cell

In order to: Optimize the neighborhood & frequency planningImprove the network coverageDetect faulty hardware components responsible for bad QoSHelp logical parameters fine tuning

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

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






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 templatesRMS templates provide means to tune RMS parameters according to Cell Planning (cell profile, cell class)

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

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

Templates parameters define the intervals or Received level, Consecutive frame erasure, Radio link counter, Path balance, C/I …for which RMS counters are provided.

BinhPT

HighLight

BinhPT

Typewriter

T110: from 10:00 ~ 14:00. Duration 1 hour --> 5 reports T31: from 10:99 ~ 14:00 --> Report






RMS Configuration in the OMC-R

RMS with OMC-R onlyTemplates are defined on the OMC-RRMS results are retrieved once a day from the BSCBinary files can be exported for post-processing

PM

RMS in binary filesTemplatesTemplates






RMS Configuration in RNO

RMS with OMC-R, NPA & RNO

Templates are defined on RNORMS results are retrieved once a day from the BSCBinary files are transferred to NPARMS warnings on NPARMS QoS reports on RNORMS reports used in RNO

CheckQoS follow-upDiagnosisTuning

The Experience matrix can be generated for network planningExcel export is adapted to RMS

Benefit to whole RNO

Templates

PMComputeexperience

matrix

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. RNO defines and sends RMS templates to the OMC-R

2. The OMC-R activates an RMS campaign in the BSS

3. RMS counters are transferred tothe OMC

4. RMS counters are stored in NPA

5. RMS indicators requested by RNO

6. RMS QOS report displayed7. RNO calculates and

exports the Experience matrix to RNP

A9156 RNO

NPA

RNP

OMC-R

BSS

Template

1

Experience matrix

7

PM4

2PM

3

5QOS

6

QOS

The tuning function of RNO defines a preferred RMS template depending on cell characteristics (type, class, capacity, etc.).

RNO manages the frequencies to monitor through MAFA jobs depending on the neighborhood and the frequency bands.

RNO is a reference for RMS templates:

16 templates stored in the RNO database,

Reference values for templates available,

Extra editor in the administration tool to modify templates: a given value or a reference one.

NPA

NPA stores RMS jobs measurements, at Cell & TRX levels (15 days).

NPA makes some consolidations (voice quality, averages, etc.).

NPA manages some warnings on RMS indicators (path balance).

The Experience Matrix generated by RNO is an interference matrix computed from C/I measurements provided through RMS counters.






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 typedin ITALIC and underline





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 qualCFE AMR (Analyze the coded values) Timing Advance

C/I Statistics on neighboring freq/MAFA freqlast 2 statistics types based on samples corresponding to measurement results

Call Drop with specific radio causesUL/DL level, UL/DL qualToo long/short MS-BS distanceToo high interference UL/DL Annex 1

B10

B10

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






4.1 Generalities

Suspecting a Voice Quality problemPercentage of Noisy calls

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 RNO tool per TRX, per Cell:

Number of Noisy calls suffering from problem of bad coverage on the uplink pathRMVQULVN = RMS_call_noisy_UL_bad_coverage

Number of Noisy calls suffering from problem of interference on the uplink pathRMVQUIFN = RMS_call_noisy_UL_interference

Number of Noisy calls suffering from problem of interference and bad coverage considered together on the uplink pathRMVQUUKN = RMS_call_noisy_UL_undefined

Rate of Noisy calls suffering from problems of interference or/and bad coverage on the uplink pathRMVQUNOR = RMS_call_noisy_UL_rate

Note: The 4 indicators above can be provided for Noisy calls suffering from VQ problems on the dowlink path.

Rate of Noisy calls but with good FER measurements on the uplink pathRMVQFEGR = RMS_call_noisy_good_FER_rate

Rate of Noisy calls and also with bad FER measurements on the uplink pathRMVQFEBR = RMS_call_noisy_bad_FER_rate

Rate of calls with fair quality measurements but with bad FER measurements on the uplink pathRMVQFEAR = 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 MeasurementsSACCH meas.

begin end

CALL

480ms

CQS1 CQS2 CQS3 CQS4 CQS5 CQS6 CQS7 CQS8 CQS9 CQS10 CQS11 CQS12 CQS13 CQS14 CQS15 CQS16 CQS375

1 measurement report⇔

1 SACCH mfrVQ_AVERAGE = 4 SACCH

AV_RXLEV_UL_VQ = (RxlevUL1+RxlevUL2+RxlevUL3+RxlevUL4) / 4AV_RXLEV_DL_VQ = (RxlevDL1+RxlevDL2+RxlevDL3+RxlevDL4) / 4AV_RXQUAL_UL_VQ = (RxqualUL1+RxqualUL2+RxqualUL3+RxqualUL4) / 4AV_RXQUAL_DL_VQ = (RxqualDL1+RxqualDL2+RxqualDL3+RxqualDL4) / 4AV_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

CQS: Call Quality Sample

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

AV_RXLEV_xx_VQ = Average xx level measured over a Call Quality Sample (VQ_AVERAGE SACCH)

AV_RXQUAL_xx_VQ = Average xx quality measured over a Call Quality Sample (VQ_AVERAGE SACCH)

BinhPT

Typewriter

RxQual: from 0 -- 7 0: BER<0.27 7: BER > 12.87







Classification of a CQS and Noisy Call identificationHow to qualify the quality of a call? By looking at the repartition of the CQS!

quality

Level (dBm)

7

0

-110 -47VQ_RXLEV

bad quality + good level

interfered CQS

bad quality & level

bad coverage CQS

VQ_RXQUAL

CQS

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 StatisticsParameters 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)

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%)


RMSpg = PAR_VQ_GOOD_RXFER

RMSph = PAR_VQ_ BAD_RXFER

RMSpi = PAR_VQ_INTF_THRESHOLD

RMSpj = PAR_VQ_FER_THRESHOLD






4.2 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_RXQUALand AV_RXLEV_UL_VQ>VQ_RXLEV

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.2 Call Quality Counters [cont.]

RMS counters

VQ_NOISY_UL_INTERFERENCE = RMS10Number of calls suffering from interference problem on the uplink pathVQ_NOISY_DL_INTERFERENCE = RMS11Number of calls suffering from interference problem on the downlink pathVQ_NOISY_UL_COVERAGE = RMS12 Number of calls suffering from bad coverage problem on the uplink pathVQ_NOISY_DL_COVERAGE = RMS13Number of calls suffering from bad coverage problem on the downlink path

RMS10 = VQ_NOISY_UL_INTERFERENCE is incremented whenever a call verifies: 100*(INTERFERED_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLDwith

INTERFERED_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL and AV_RXLEV_UL_VQ>VQ_RXLEV

consideringAV_RXQUAL_UL_VQ: average on VQ_AVERAGE measurements of RXQUAL_ULAV_RXLEV_UL_VQ: average on VQ_AVERAGE measurements of RXLEV_ULNUM_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_THRESHOLDwith

INTERFERED_DL_SAMPLES = nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL and AV_RXLEV_DL_VQ>VQ_RXLEV

consideringAV_RXQUAL_DL_VQ: average on VQ_AVERAGE measurements of RXQUAL_DLAV_RXLEV_DL_VQ: average on VQ_AVERAGE measurements of RXLEV_DLNUM_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_THRESHOLDwith BAD_COVERAGE_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL and

AV_RXLEV_UL_VQ<=VQ_RXLEVRMS13 = VQ_NOISY_DL_COVERAGE is incremented whenever a call verifies: 100*(BAD_COVERAGE_DL_SAMPLES /

NUM_DL_SAMPLES) > VQ_INTF_THRESHOLDwith 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 = RMS14Number 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

RMS14 = VQ_NOISY_UL_UNDEFINED is incremented whenever a call verifies: 100*(BAD_COVERAGE_UL_SAMPLES / NUM_UL_SAMPLES) <= VQ_INTF_THRESHOLDand 100*(INTERFERED_UL_SAMPLES / NUM_UL_SAMPLES) <= VQ_INTF_THRESHOLDand 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_RXQUALand 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_THRESHOLDand 100*(INTERFERED_DL_SAMPLES / NUM_DL_SAMPLES) <= VQ_INTF_THRESHOLDand 100*(BAD_QUALITY_DL_SAMPLES / NUM_DL_SAMPLES) > VQ_INTF_THRESHOLD

withBAD_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 = RMS16Number 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 = RMS17Number of calls with bad quality measurements but with good FER measurements on the uplink path

VQ_ABNORMAL_BAD_FER = RMS18Number of calls with fair quality measurements but with bad FER measurements on the uplink path

RMS16 = VQ_NOISY_UL_BAD_FER is incremented whenever a call verifies: 100*(BAD_QUALITY_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLDand 100*(BAD_QUAL_BAD_FER_UL_SAMPLES / BAD_QUALITY_UL_SAMPLES) > VQ_FER_THRESHOLD

withBAD_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

consideringAV_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_THRESHOLDand 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

withFAIR_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






5.1 Generalities

Suspecting a TRX hardware problemAverage path balance


Vector of the Number of Measurement Results per Path Balance bandRMPBV = RMS_PathBalance_sample

Average Path Balance valueRMPBAN = RMS_PathBalance_avg

A Templates modification is needed to have more details.







Vector CounterRMS7a=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

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 repartitionTA repartition (improved)







TPR_RXQUAL_UL_RXLEV_ULTPR_RXQUAL_UL_RXLEV_UL TMR_RXQUAL_UL_RXLEV_ULTMR_RXQUAL_UL_RXLEV_UL

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

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

S(RXQUAL i, RXLEV band j) x Max j / 254

TPR_RXQUAL_UL_RXLEV_UL(i,j) x TMR_RXQUAL_UL_RXLEV_UL(j) / 254






5.2 Radio Quality Parameters

RMS ParametersRadio Quality Statistics: Parameters used to define intervals for RXLEV, Path Balance, Radio Link Counter and Consecutive Frame Erasure, TA statisticsNo 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


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 dBmvalue according to the frequency band of the TRX.

BS_TXPWR is the BTS transmitted power offset defined relatively to the maximum absolute output power of the BTS (negative value in dB).

BTS_MAX_OUTPUT_POWER is the maximum power of the BTS after Combiner (in dBm).

RXLEV_DL is the received signal levels measured by the MS on the downlink path (in dBm).

NOTE: Additional asymetric DL loss (external combiner) or UL gain (TMA) are not taken into account in the computation, so they must be considered when interpreting the RMS results.






5.2 Radio Quality Parameters [cont.]

RMS ParametersRadio 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 basisS = RADIOLINK_TIMEOUT_BS if good radio conditionsS decremented if bad radio conditionsThe BSS triggers a call drop when S = 0


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 TA9a 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 ParametersRadio 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)

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

SACCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

SACCH mfrTDMA: 4,616ms

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

SACCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

SACCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

SACCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

TCH

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


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 RNO tool.

Note: By default, a BFI relates to a speech frame. When considering SACCH measurement, SACCH_BFI should be used.

BinhPT

HighLight






5.3 Radio Quality Counters

RMS CountersRadio 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 jMS PWR levelij: average value of MS power (in dBm) from pwr levels reported in these samplesTiming 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

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 jBS PWR levelij: average value of BS power (in dBm) from pwr levels reported in these samplesTiming 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

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)

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)

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

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 CountersRadio 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 countedsequences of not decoded speech frames are cumulated

SACCH mfr

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

BFI

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.

0 0 0 1 0 0 0 1 1 1 1 0 0 1 1 0 1 1 1 0 1 0 1 1 0

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









RMS Counters for AMR MonitoringRadio Quality StatisticsTo 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)









RMS Counters for AMR MonitoringRadio Quality StatisticsAMR 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)









RMS Counters for AMR MonitoringRadio Quality StatisticsAMR 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.

AMR-FR codec usage compared to RXLEV

RXLEV UL bands are defined as follows:







RMS Counters for AMR MonitoringRadio Quality StatisticsAMR 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.

AMR-HR codec usage compared to RXLEV

RXLEV UL bands are defined as follows:







RMS Counters for Timing AdvanceRadio 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

Corresponding RMS counter numbers:

RMS36 = PERC_TA_GT_TA_STAT

RMS37 = MAX_TA



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: 0 <= TA < Meas_STAT_TA_1

TA band 2 is defined by: 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 AdvanceA 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.



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 AdvanceA new set of RMS counters related with timing advance analysis.Uplink:

TPR_UL_RXQUAL_TA_BAND= RMS53: Table of 10 results that has 10 cells (1 for each timing advance band) with average of uplink rxqual in corresponding timing advance band.

Downlink:TPR_DL_RXQUAL_TA_BAND= RMS54 Table of 10 results that has 10 cells (1 for each timing advance band) with average of uplink rxqual in corresponding timing advance band.



MAX_POWER_PER_TRX= RMSPw3

Maximum GMSK TRX power level applied at the BTS antenna output connector in dBm.

The power takes into account the different losses (cables, internal combiners) and the internal/ external leveling but it does not take into account the BS-TXPWR-MAX, attenuation required by the OMC_R.

If the feature “unbalancing TRX output power per BTS sector" is activated (parameter “En-Unbalanced-Output-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).





RMS Counters for Timing AdvanceMAX_POWER_PER_TRXMaximum 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





6 C/I Statistics





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





6 C/I Statistics

6.2 C/I Parameters

RMS ParametersC/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 dBEN_BALANCED_CI: boolean indicating if the C/I value reported by the BTS is balanced or notNEIGB_CELL_ID: (BCCH,BSIC) of the neighboring cell for which the C/I statistics per neighboring cell are reportedFrequency ARFCN: ARFCN of the frequency for which the C/I statistics per MAFA frequency are reported

Annex 2


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

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.

RMS8a=TPR_CIN RMS8b=TMR_CIN





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)

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.

RMS9a=TPR_CIF RMS9b=TMR_CIF





7 Call Drop with Specific Radio Causes






7.1 Generalities

The objective is to associate a specific radio cause (too low level, too bad quality, etc.) to each call drop, in the RMS statistics. Each time a BSS triggered call release happens, the BSC shall use the last measurements received for this MS to compute what is the probable cause of the drop

According to some thresholdsIf several causes are eligible, only the one with the highest priority shall be reported.Could then be used to increment counters

B10

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











7.2 Thresholds for Detection

Condition to trigger a reported HO cause

B10

Condition verified by last MS measurements Cause to be reported in counters

Priority

AV_RXQUAL_UL_HO > L_RXQUAL_UL_H + OFFSET_RXQUAL_FHAnd

AV_RXLEV_UL_HO <= RXLEV_UL_IHAV_RXQUAL_DL_HO > L_RXQUAL_DL_H + OFFSET_RXQUAL_FHAnd

AV_RXLEV_DL_HO <= RXLEV_DL_IHAV_RXQUAL_UL_HO <= L_RXQUAL_UL_H + OFFSET_RXQUAL_FHAndAV_RXLEV_UL_HO < L_RXLEV_UL_HAV_RXQUAL_DL_HO <= L_RXQUAL_DL_H + OFFSET_RXQUAL_FHAndAV_RXLEV_DL_HO < L_RXLEV_DL_HAV_RANGE_HO > U_TIME_ADVANCE Too long MS-BS distance 5AV_RANGE_HO ≤ L_TIME_ADVANCE Too short MS-BS 6AV_RXQUAL_UL_HO > THR_RXQUAL_CAUSE_15 + OFFSET_RXQUAL_FHAndAV_RXLEV_UL_HO > RXLEV_UL_IHAV_RXQUAL_DL_HO > THR_RXQUAL_CAUSE_16 + OFFSET_RXQUAL_FHAndAV_RXLEV_DL_HO > RXLEV_DL_IH

Too high interference in the uplink

7

Too high interference in the downlink

8

Too low level in UL 3

Too low level in DL 4

Too low quality in UL 1

Too low quality in DL 2

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











7.3 Counters

Counters for each Handover cause detected

B10

Short Name Name Definition

MC928aNB_TCH_DROP_CAUSE_TOO_LOW_QUALITY_UL

Number of TCH drops due to Cause 2 (Too low quality in UL).

MC928b NB_TCH_DROP_CAUSE_TOO_LOW_LEVEL_ULNumber of TCH drops due to Cause 3 (Too low level in UL).

MC928cNB_TCH_DROP_CAUSE_TOO_LOW_QUALITY_DL

Number of TCH drops due to Cause 4 (Too low quality on the downlink).

MC928d NB_TCH_DROP_CAUSE_TOO_LOW_LEVEL_DLNumber of TCH drops due to Cause 5 (Too low level in DL).

MC928eNB_TCH_DROP_CAUSE_TOO_LONG_MS_BS_DISTANCE

Number of TCH drops due to Cause 6 (Too long MS-BS distance).

MC928fNB_TCH_DROP_CAUSE_TOO_SHORT_MS_BS_DISTANCE

Number of TCH drops due to Cause 22 (Too short MS-BS distance).

MC928gNB_TCH_DROP_CAUSE_TOO_HIGH_INTERFERENCE_UPLINK

Number of TCH drops due to Cause 15 (Too high interference level on the uplink).

MC928hNB_TCH_DROP_CAUSE_TOO_HIGH_INTERFERENCE_DOWNLINK

Number of TCH drops due to Cause 16 (Too high interference level on the downlink).

MC928i NB_TCH_DROP_OTHER_CAUSES

Number of TCH drops due to other causes than Cause 2 (Too low quality in UL), Cause 3 (Too low level in UL), Cause 4 (Too low quality on the downlink), Cause 5 (Too low level in DL), Cause 6 (Too long MS-BS distance), Cause 15 (Too high interference level

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






BinhPT

Ellipse

BinhPT

Typewriter

Don't need to take care

BinhPT

HighLight





8 RMS Indicators Usage






8.1 Suspecting a Voice Quality Problem

Percentage of Noisy calls

FER is more reliable than RXQUAL to assess VQNoisy calls indicators can also be computed from FER measurements

Noisy calls with bad or good FERCalls not detected as noisy but with bad FER

Voice Quality indicators are based on calls

Noisy calls are associated with a cause of bad coverage,

interference or with an undefined cause

The fact that FER measurements are more reliable than RXQUAL ones to assess the VQ is even more true when using Slow Frequency Hopping. In this case, RXQUAL values are not anymore correlated to Voice Quality as perceived by the end user.

FER measurements are available for the uplink path only.


Number of Noisy calls suffering from problem of bad coverage on the uplink pathRMVQULVN = RMS_call_noisy_UL_bad_coverage

Number of Noisy calls suffering from problem of interference on the uplink pathRMVQUIFN = RMS_call_noisy_UL_interference

Number of Noisy calls suffering from problem of interference and bad coverage considered together on the uplink pathRMVQUUKN = RMS_call_noisy_UL_undefined

Rate of Noisy calls suffering from problems of interference or/and bad coverage on the uplink pathRMVQUNOR = 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 pathRMVQFEGR = RMS_call_noisy_good_FER_rate

Rate of Noisy calls and also with bad FER measurements on the uplink pathRMVQFEBR = RMS_call_noisy_bad_FER_rate

Rate of calls with fair quality measurements but with bad FER measurements on the uplink pathRMVQFEAR = 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.






8.2 Suspecting a Cell Coverage Problem

Distribution of samples per RxQual value and RxLev band

Distribution of samples per RxLev band

Not acceptablecoverage limit: Too low level Too bad quality

A coverage problem is observed when a significant amount of the traffic of a cell is suffering from both low level and bad quality (RxQual).

To confirm the distribution of samples per RXLEV band, should be also considered to know the proportion of calls which are experiencing a low signal level.

If a lot of samples of low level and bad quality are observed for only a sub-part of the TRXs (can be one only) then a BTS hardware problem or a problem on the aerials should be suspected.

If all the TRXs are experiencing a lot of samples of low level and bad quality then a coverage problem shall be suspected.


Matrix of Number of Measurement Results per DL RxQual value and per DL RxLev bandRMQLDSAM = RMS_DL_RxQuality_RxLevel_sample

Vector of Percentage of Samples per DL RxLev bandRMQLDLVDV = RMS_DL_RxLevel_distrib

Vector of Percentage of Samples per DL RxQual bandRMQLDQUDV = RMS_DL_RxQuality_distrib






8.2 Suspecting a Cell Coverage Problem [cont.]

Average TA values per RxQual value and RxLev band

Not acceptablecoverage 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

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 bandRMQLUTAM = RMS_UL_RxQuality_RxLevel_TimingAdvance

Rate of Measurements Results whose TA is greater than the TA thresholdRMTAGTR = RMS_TimingAdvance_greater_threshold_rate

Maximum TA value of all values reported in Measurement Results RMTAMXN = RMS_TimingAdvance_max






Exercise 1

Give the list of the RMS counters and parameters used in the 3 previous slides.

Time allowed:

10 minutes






Exercise 2

Interpret this graph.

Time allowed:

10 minutes






8.3 Suspecting a Cell Interference Problem

Number of samples per RxQual value and RxLev band

Average DL RxQuality = 0.34

RMS results show no problemof radio link quality in this cell

Average RxQual value per RxLev band has also to be considered


Matrix of Number of Measurement Results per DL RxQual value and per DL RxLev bandRMQLDSAM = RMS_DL_RxQuality_RxLevel_sample

Vector of Average DL RxQual per RxLev bandRMQLDQUAV = RMS_DL_RxQuality_avg_per_RxLevel

Average DL RxQualityRMQLDQUAN = RMS_DL_RxQuality_avg






Exercise 3


Average RxQual value per RxLev band has also to be considered

Average DL RxQuality = 2.81






Exercise 4


Time allowed:

15 minutes






Exercise 5


Time allowed:

10 minutes






Exercise 6

Compute the RMS counters and indicators in the file.

Time allowed:

10 minutes





9 Additional Information






RMS Counters

Counters used for post-processing the RMS results provided per TRXTOT_SEIZ_TCH: number of TCH channels successfully seized by the MSTOT_MEAS: number of Measurement Results used for RMSTOT_MEAS_L1INFO_NOL3INFO: number of Measurement Results used for RMS statistics for which Layer 1 info is present but Layer 3 is missingTOT_MEAS_DTX_UL: number of Measurement Results used for RMS statistics for which DTX UL was used in the corresponding SACCH mfrTOT_MEAS_DTX_DL: number of Measurement Results used for RMS statistics for which DTX DL was used in the corresponding SACCH mfrTOT_EMR: number of Extended Measurement Results used for RMS statistics


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 anychannel 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 campaignIND_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

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 campaignC/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)


RMS23 = IND_CI_PARTIAL_OBSERVATION

RMS24 = IND_CI_OVERFLOW





End of ModuleRadio Measurement Statistics Indicators





Module 7Traffic Indicators3JK11049AAAAWBZZA Issue 01








Blank Page




Document History





Module Objectives


Describe BSS traffic indicators used for radio resource dimensioning





Table of Contents


1 Call Mix Definition 72 Basis of Traffic Theory 153 TCH Resource Allocation Indicators 294 Resource Occupancy Indicators 345 Traffic Model Indicators 376 Preemption Indicators 40





1 Call Mix Definition






GSM Transactions

In a GSM Network, there are a lot of different transactions: location update: periodic, new updating, ~imsi_attach, ~imsi_detachHand Over (intra-cell, internal, external, etc.)SMS (Short Message Service, originating or terminating)SS (Supplementary Service) (i.e: number presentation)Pagingand also Originating and Terminating calls, etc.and so on (data, SMS-CB, etc.)

In a GSM network, telecom procedures involve different kinds of resource 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 SMSs5 SSs6000 pagingsWith the following characteristicsmean call duration on TCH: 50 secondsmean SDCCH duration: 3.2 seconds

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 : 900 (2/3 TC)LU/call : 4HO/Call : 1.5 (2/3 internal, 1/3 external)SMS/Call : 11 %SS/call : 5 %Paging/hour : 6000mean call duration on TCH : 50 secondsmean SDCCH duration : 3.2 seconds

After commercial opening, the number of calls per hour will be measured from traffic counters.

Usually the Marketing team will provide:

on a per geographical area or morphostructure basis:

the traffic per km2 (in Erlang),

the traffic per subscriber (in mErl).

the number of calls per hour.






Variation

A call mix is varying a lot: from a cell to another

TCH traffic (induced by subscribers)number of LU/call and HO/call (induced by network design)

from one hour to anotherby default: busy hour

from one year to anothermodification of traffic intensity and distribution

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






Usage

Interests of call mix: Input data for dimensioningCell and BSC resources dimensioning

RTCH, SDCCH, TTCH, BTS, BSC and MSC CPU processorSome examples of "risky" call mix

too many LU/Calls: SDCCH congestion, TCU load, MSC overloadtoo many HO/calls: speech quality, call drop, DTC loadtoo many calls: TCH congestiontoo many paging: DTC processor load, PCH congestion

A Call Mix will be used at Radio Network Design and Radio Network Planning stages in order to define the capacity of the network (number of sites, TRXs per site, radio configuration, number of Abis-PCM, A-PCM).

When the network is in operation, a Call Mix is used in order to anticipate network extension or re-dimensioning.






Advises

Some advises

LU/CALL: 1 is "good", 2 is "bad", 4 and more can be dangerousbeware 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)






Exercise

Compute the call mix of a cell according the following information:256 calls/hour1300 LUs/hour450 HOs/hour

Is it complete? What are the risks of such a call mix?

Time allowed:15 minutes





2 Basis of Traffic Theory






Erlang Definition

ERLANG: unit used to quantify traffic (intensity)T = (resource usage duration) / (total observation duration) [ERLANG]

Example: For 1 TCH, observed during 1 hourone can observe 2 calls: 1 of 80 seconds and 1 of 100 seconds

T = (80+100)/3600 = 0.05 ERLANG






Erlang from Call Mix

Call mix example: 350 calls/hour3 LUs/callTCH mean call duration: 85 secondsSDCCH mean duration: 4.5 seconds

Computation of Carried Erlang TCH = (350*85)/3600: 8.26 ERLANGSSDCCH = [ (350+350*3) * 4.5 ] / 3600 = 1.75 Erlang






Erlang B Law

In a Telecom system, the call arrival frequency is ruled by the POISSON lawErlang B law: relationship between:

offered trafficnumber of resourcesblocking rate






Erlang B Law [cont.]

The call request arrival rate (and leaving) is not stablenumber of resources = average number of requests * mean duration

is sometimes not sufficient => probability of blocking

=> Erlang B law Pblock: blocking probabilityN: number of resourcesE: offered traffic [Erlang]

Good approximation when the blocking rateis low (< 5 %)

Telecom system

Offered Carried

Rejected

Pblock N

k

N

k

k

N

EE

=

=∑!

!0

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)






Erlang B Abacus






Erlang B Example

Example: 1 cell with 8 TRXs, with 60 TCH channelsMaximum blocking rate: 2 %

Erlang law: 50 Offered Erlang

83 % of TCH resources used to reach 2% of blocking






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 E25% resources used to reach 2% blocking

if we decide to provide SMSCB (Cell Broadcast information), 1 SDCCH stolen for CBCH

3 SDCCHs, Pblock = 2% => T = 0.6 E25% resources less => 50% Traffic less!!






Cell Dimensioning

Given an Offered traffic, compute the number of TRXs (and SDCCH) needed to carry it => What is the accepted blocking rate?

Default blocking rateRTCH: 2 %SDCCH: 0.5 %(for BSC TTCH: 0.1%)

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%) = 19example: 3 TRXs, 21 TCHs, 1 BCCH, 2 SDCCHs/8






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






Forecast / Critical Traffic

Forecast traffictraffic forecasting must be computed according to the offered traffic

not directly on the measured trafficIn order to plan the necessary actions soon enough, one must compute regularly the date when the traffic of a cell will become critical

Critical trafficcritical traffic: when the offered traffic will induce 2% of blocking traffic capacity of a cell = critical traffic of this cell






Exercise

Complete the form to get less than 2% of blocking.

cell call mix info Erlang TCHOffered traffic

traffic forecast proposed config

12, 743 450 call/hourmean TCH call duration : 80secblocking rate TCH : 0.8%

10,08 Erlang TCH 30 % offered trafficincrease

13,1 Erlang TCH - > 20 TCH3 TRX

12,675 330 call/hourmean TCH call duration 129secblocking rate 4%

30 % offered trafficincrease

12,865 600 call/hourmean TCH call duration 96secblocking rate 8 %

30 % offered trafficincrease





3 TCH Resource Allocation Indicators






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 operatorsorting 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 mobilethe TRE DR capability and the TRE band

selecting the best TCH resource among the available TCH channels of this pool according to several criteria






MS Access

MS access types distribution (NA only)Accessibility in type 110 since B8

TCH requests from FR only MSTCNARQMN= MC701A

TCH requests from DR MSTCNARQBN= MC701B

TCH requests from DR+EFR MSTCNARQTN= MC701C

TCH requests from AMR MSTCNA3RQTN= MC701D

TCH requests from Data callsTCNARQDN= MC701E


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 B8TCH allocations with FR SV1

TCNACAFN= MC702ATCH allocations with HR SV1

TCNACAHN= MC702BTCH allocations with FR SV2 (EFR)

TCNACAEN= MC702CTCH allocations with FR SV3 (AMR FR)

TCNA3CAFN= MC704ATCH allocations with HR SV3 (AMR HR)

TCNA3CAHN= MC704BTCH allocations for data call

TCNACADN= MC705



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 ratioTCAHCAFO = MC370A / (MC370A+MC370B)HR TCH allocation ratioTCAHCAHO = MC370B / (MC370A+MC370B)

NA/HO distribution Normal Assignment TCH allocation ratioTCNACAO = MC703 / (MC703 + [MC15A+MC15B])Handover TCH allocation ratio TCHOCAO = [MC15A+MC15B] / (MC703 + [MC15A+MC15B])

TCH allocation distribution per TRXNumber of TCH allocations for Normal AssignmentTCNACAN = MC703

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 AssignmentMC15A = Number of TCH allocations for Internal Directed RetryMC15B = Number of TCH allocations for Handover (intra cell, internal, external)

TCNACAN indicator is also available as the MAX value of the day on the A9156 RNO tool.

Some of these indicators are also available for SDCCH: SDCCH allocation distribution per TRX through the number of SDCCH allocationsSDAHCAN = MC390SDCCH Assignment/HO distribution through the ratio of SDCCH allocations for AssignmentSDNACAO = MC148 / MC390





4 Resource Occupancy Indicators






TCH Resource

TCH resource occupancyTCH traffic in Erlang

TCTRE= (MC380A+MC380B) / 3600TCH mean holding time (TCH average duration)

TCTRMHT= (MC380A+MC380B) / (MC370A+MC370B)FR TCH traffic in Erlang

TCTRE= MC380A / 3600FR TCH mean holding time

TCTRFMHT= MC380A/ MC370AHR TCH traffic in Erlang

TCTRE= MC380B / 3600HR TCH mean holding time

TCTRHMHT= MC380B/ MC370B


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






SDCCH / ACH Resource

SDCCH resource occupancySDCCH traffic in Erlang

SDTRE= MC400 / 3600SDCCH mean holding time (SDCCH average duration)

SDTRMHT= MC400 / MC390

ACH resource occupancyACH traffic in Erlang

C750 / 3600ACH mean holding time (ACH average duration)

QSTRN =C750 / C751

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






SDCCH Establishment

SDCCH establishment cause distributionRatio of MT calls

TMMTO= MC01 / SDCCH ASSIGN SUCCESSRatio of MO normal and emergency calls

TMMTO= MC02H / SDCCH ASSIGN SUCCESSRatio of LU normal (resp. follow-on)

TMMOLUR = MC02A (resp. MC02D) / SDCCH ASSIGN SUCCESSRatio of IMSI detach

TMMOLUDR= MC02G / SDCCH ASSIGN SUCCESSRatio of Short Message Service

TMMOSMSR= MC02B / SDCCH ASSIGN SUCCESSRatio of Supplementary Service

TMMOSSR= MC02C / SDCCH ASSIGN SUCCESSRatio of Call re-establishment

TMMOCRR= MC02E / SDCCH ASSIGN SUCCESS

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

E-GSM mobiles penetrationRatio of E-GSM MS access over all MS accesses (except LU)TMMSEGR = MC706 / ([MC01+MC02]-[MC02A+MC02D+MC02G])

Multiband mobiles penetrationRatio of Multiband MS access over all MS accesses (except LU)TMMSMBR = MC850 / ([MC01+MC02]-[MC02A+MC02D+MC02G])

AMR mobiles penetrationRatio of TCH allocation for AMR MS over all TCH allocationsTCTR3CATTO = MC704A+ MC704B / MC703

TFO calls ratioRatio of successful TFO establishment over all TCH allocationsQSTRCCTR = MC170 / MC703

Handover per CallNumber of Handovers (intra cell, internal, external) per Normal AssignmentTMHOCO = (MC717A+MC717B) / MC718

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: Traffic Load and Traffic Model > SDCCH traffic > MS penetration rate


[MC01+MC02]-[MC02A+MC02D+MC02G] = Total number of initial accesses for call establishment (except location update)

MC706 = Number of initial accesses for call establishment (except location update) of MS supporting the E-GSM band

MC850 = Number of initial accesses for call establishment (except location update) of MS supporting two frequency bands (ex: GSM900 and DCS1800)

MC703 = Total number of TCH allocations (FR+HR) for Normal Assignment

MC704A = Number of TCH allocations (FR) for Normal Assignment of AMR mobiles only

MC704B = Number of TCH allocations (HR) for Normal Assignment of AMR mobiles only

MC704 (Allocation AMR FR+HR) is removed in B8

MC170 = Number of TCH calls for which a TFO has been successfully established





6 Preemption Indicators






Preemption Principle

Preemption attributes (in Assignment or HO Request): pci: preemption capability indicationindicates if the call can preempt another call (pci=1) or notpvi: preemption vulnerability indicationindicates if the call is preemptable (pvi=1) or notpriority 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 pcivalue)the on-going call with the lowest priority level value shall be electedfirst and if several calls have the same lowest p2 value, one of them with pci bit set to 0 is preferred

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 preemptanother 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 callsMC921D = Number of preemption capable TCH Request (pci=1) successfully served in a neighboring cell with the help of the directed retry procedureMC921E = Number of preemptable calls successfully established (pvi=1)

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: GLOBAL Quality of service INDICATORS> RTCH > Preemption feature






Preemption Feature

Preemption capable TCH Request rejection rateTCPPFLCR = (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 callsTCPPSUVO = MC921E / (MC718+MC717A+MC717B)

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:GLOBAL Quality of service INDICATORS> RTCH > Preemption feature





End of ModuleTraffic Indicators





Module 8Case Studies









Blank Page




Document History





Module Objectives


Analyze with the KPI QoS some typical problems





Table of Contents


1 Congestion 72 Sector Problem 93 QSCSSR 114 Quality 135 RMS Level 156 Interference 177 BSS Problem 19





1 Congestion





1 Congestion

Congestion Analysis

From this RNO 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 %





2 Sector Problem





2 Sector Problem

Scetor Problem Analysis

In this trisectorised site,give the worst sector.

What can you propose to do?





3 QSCSSR





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_successRTCH_ass_Un_%= RTCH_assign_unsuccess / RTCH_assign_request

143084TCH normal assignment successes (HR or FR)MC718

QSCSSR=?

00SDCCH drops during any outgoing SDCCH handoverMC07

145588normal assignment requests for TCH establishment (HR or FR)MC140a

1352663SDCCH assign success for Mobile Originating procedureMC02

92443SDCCH assign success for Mobile Terminating procedureMC01

21SDCCH drops in SDCCH established phase due to BSS problemMC137

49SDCCH drops on SDCCH established phase due to Radio Link Fail.MC138

Paris_City_S3Paris_Tower_S1DefinitionCounter





4 Quality





4 Quality

Quality Analysis

Analyze the table below.

Does it seem to be a good HO causes repartition?What can we check to analyze the problem?

Repartition HO Quality 22/01/2003 23/01/2003 24/01/2003 25/01/2003 27/01/2003 28/01/2003 29/01/2003 30/01/2003DL_QUAL 64 63 69 58 26 36 32 34

% DL_QUAL 3.12% 2.76% 3.27% 3.22% 1.30% 1.94% 1.69% 2.64%UL_QUAL 55 51 433 263 338 466 1053 348

% UL_QUAL 2.68% 2.23% 20.54% 14.59% 16.93% 25.09% 55.68% 27.00%Nber of HO 2054 2286 2108 1802 1996 1857 1891 1289





5 RMS Level





5 RMS Level

RMS Level Analysis

Find the 2 worst cells in the table. Try to propose a solution!





6 Interference





6 Interference

Interference Analysis

Find 1 bad cell with some HO problem.What can you propose to do?





7 BSS Problem





7 BSS Problem

BSS Problem Analysis

What is the worst cell? Propose some probable solutions.





End of ModuleCase Studies





Module 9Annexes

3JK11051AAAAWBZ Issue 01








Blank Page




Document History





Module Objectives


Describe …List …Explain …Identify ...





Table of Contents


1 Radio Measurement Reporting 72 Extended Measurement Reporting (MAFA) 113 Directed Retry Indicators 144 GSM BSS Protocol Stacks 325 LCS 426 Counters on Electromagnetic Emission (EME) 657 B8 Improvements 698 B9 Improvements 719 Dynamic SDCCH Allocation 7310 Handover Detection for Concentric Cells 83





1 Radio Measurement Reporting






Radio Measurement Mechanisms

MS connected (TCH or SDCCH)The serving cell gives to the MS the list of the neighboring cells to listenEvery 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






Radio Measurement Mechanisms [cont.]

For each MS connected to the BTS (TCH or SDCCH)

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

Meast

Report

Meast

Result






Measurement Result Message

L1 Info

L3 Info

MeasurementReportFrom the MS

Back

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)






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 listSuch phase 2+ mobiles must support the optional Mobile Assisted Frequency Allocation (MAFA) feature









< --------------------------------------------------------CHANNEL ACTIVATION (TCH)

(EMO included)-------------------------------------------------------- >CHANNEL ACTIVATION ACKNOWLEDGE

.

.TCH establishment.

--------TCH---------> .ASSIGNT COMPLETE ------------------------------------------------------- >

ASSIGNMENT COMPLETE ----------------------------------- ><------SACCH-------- ASSIGNMENT COMPLETE

--------SACCH------><------SACCH--------

--------SACCH------><-------SACCH--------

EMO(MAFA freq. List)

--------SACCH------>EMR

(MAFA freq. RxLev)<------SACCH--------

--------SACCH------>


Extended Measurement Reporting Mechanisms

The Extended Measurement Order includes the MAFA frequencies the MS is asked to measureEMO sent once to the MS on SACCH after TCH seizureExtended Measurement Results include the average signal level measured on each MAFA frequency over one SACCH mf durationEMR received once per call on SACCH

Back

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






Internal DR - Success Case

DR FAIL. CASES > internal DR > success caseThe same internal DR procedure leads to an incrementation of two sets of counters:

incoming DR counters for the target cell: MC153, MC151, etc.outgoing DR counters for the serving cell: MC144E, MC142E, etc.

MCx counters belong to Standard Type 110 reported permanentlyCx counters belong to Detailed Type 29 reported on demandStandard type from B8

MS serving cell target cell BSC MSCTCH ASSIGNMENT PHASE (OC or TC)

< -----------------------ASSIGNMENT

REQUESTNo free TCH

TCH request queuedQueuing allowed

Start T11 ----------------------- >QUEUING_INDIC.

MC13A

IDR condition met MC153, MC144e,

CHANNEL ACTIV. (TCH)<---------------------------------- MC15A

CHAN ACTIV ACK---------------------------------->

HO CMD HANDOVER COMMAND<----------------------

(SDCCH)<------------------------------------------------------------------------ start T3103

C154, MC607start T3124 C145A+C145C

HANDOVER ACCESS------------------------(TCH)---------------------------->-------------------------------------------------------------> HO DETECTION

PHYSICAL INFORMATION ----------------------------------><------------------------------------------------------------- start T3105stop T3124start T200------------------------ SABM --------------------------> stop T3105<-------------------------- UA ----------------------------- ESTABLISH INDICATIONstop T200 ---------------------------------->

HANDOVER COMPLETE HO CMP stop T3103-------------------------------------------------------------> ----------------------------------> ASSIGNMENT

COMPLETE------------------------>

Release of old SDCCH MC151,MC717A,MC142e

The following DR counters are provided in Type 110for 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 ofthe 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


DR Execution: radio problem: the MS fails to access the new channel







Incoming Internal DR - Congestion

DR FAIL. CASES > Incoming internal DR fail: congestion

MC555=C155

Standard Type

MS serving cell target cell BSC MSCTCH ASSIGNMENT PHASE (OC or TC)

< ----------------------------------------------------ASSIGNMENT REQUEST

No free TCHIn serving cell

Queuing allowed

Start T11 --------------------------------------------------- >QUEUING_INDIC.

MC13A

IDR condition met MC153, MC144e,MC607

No free TCHIn target cell

MC555

C155 is available in Type 29.






Incoming Internal DR - Radio Failure

DR FAIL. CASES > Incoming internal DR fail: MS access problem


-----------------------> MEASUREMENT RESULT------------------------------------------------------------------------>


CHANNEL ACTIV ACK---------------------------------->


C154SABM

-----------x T3103 expiry C152



HANDOVER ACCESS C154------------------------------------------------------------->-------------------------------------------------------------> HO DETECTION



UA ----------------------------------><------------------------------------------------------------- stop T3105



UA ------------------------------------------------------------------------><-----------------------

HO FAILURE HANDOVER FAILURE-----------------------> ------------------------------------------------------------------------> C152


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 MC153, C153

Congestion MC555, C155BSS Pb C153-C154-C155

Attempt C154

Radio (MS access problem) C152BSS Pb C154-C151-C152

Success MC151, C151

Execution

Preparation

INCOMING INTERNAL Directed Retry

REQUEST

CONGESTION

ATTEMPT

MS ACCESS PB

BSS PB

SUCCESS

BSS PB

Preparation Failure

Execution Failure

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 failuresDirected 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: radio problem: the MS reverts to the old channelradio problem: the MS dropsBSS problem (no specific counter)






Outgoing Internal DR - Radio Failure ROC

DR FAIL. CASES > Outgoing internal DR fail: reversion old channel

C144A, C143A: Forced DR

C144C,C143E: Normal DR


HO CMD HANDOVER COMMAND<-------SDCCH----- <------------------------------------------------------------------------ start T3103

HANDOVER ACCESS MC144E----------------------TCH--------------------------------> C144A or C144C-------------------------------------------------------------> HO DETECTION



UA ----------------------------------><------------------------------------------------------------- stop T3105



UA ------------------------------------------------------------------------><-----------------------

HO FAILURE HANDOVER FAILURE-----------------------> ------------------------------------------------------------------------> C143A or C143E







Outgoing Internal DR - Radio Failure Drop

DR FAIL. CASES > Outgoing internal DR fail: drop

C144A,C143B: Forced DR

C144C,C143F: Normal DR

MS serving cell target cell BSC MSC


MC144ESABM C144A or C144C

----------x

T3103 expiryC143B or C143F------------------------>

ASSIGNMENTFAILURE

“Radio interfacemessage failure”

Release of SDCCH and TCH

Counters C144A, C143B, C144C, C143F are type 29.






Outgoing Internal DR - Counters

DR FAIL. CASES > Outgoing internal DR counters

Preparation Request MC144E, C144A+C144C

Any preparation failure (C144A+C144C) - (C145A+C145C)

Attempt C145A+C145C

Reversion old channel C143A+C143EDrop radio C143B+C143FBSS Pb (C145A+C145C) - (C143A+C143E+C143B+C143F)

Success MC142E, C142A+C142C

Execution

OUTGOING INTERNAL Directed Retry

REQUEST

CONGESTION

ATTEMPT


DROP RADIO

BSS PB

SUCCESS

BSS PB

Preparation Failure

Execution Failure




Specific indicators for densification techniques > Directed Retry > Outgoing DR

DROBSUR: global efficiency of outgoing internal DR = MC142E/MC144E

Other indicators can be computed


efficiency of the outgoing internal DR preparation = (C145A+C145C)/(C144A+C144C)

efficiency of the outgoing internal DR execution = (C142A+C142C)/(C145A+C145C)

rate of outgoing internal DR execution failures due to BSS problems = [(C145A+C145C) - (C143A+C143E+C143B+C143F)] / (C145A+C145C)

rate of outgoing internal DR execution failures due to radio problems with reversion old channel = (C143A+C143E) / (C145A+C145C)

rate of outgoing internal DR execution failures due to radio problems with drop = (C143B+C143F) / (C145A+C145C)

type 29 counters are defined:

DRFOSUIN C142a NB_OUT_FORCED_IDR_SUCC

DRFOSUEN C142b NB_OUT_FORCED_EDR_SUCC

DROBSUIN C142c NB_OUT_NOR_IDR_SUCC

DROMSUEN C142d NB_OUT_NOR_EDR_SUCC

DRFORDIN C144a NB_OUT_FORCED_IDR_REQ

DRFORDEN C144b NB_OUT_FORCED_EDR_REQ

DROBRDIN C144c NB_OUT_NOR_IDR_REQ

DROMRDEN C144d NB_OUT_NOR_EDR_REQ

DROBRQIN C145c NB_OUT_NOR_IDR_ATPT

DROMRQEN C145d NB_OUT_NOR_EDR_ATPT






External DR - Success

DR FAIL. CASES > External DR > successful case

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.

MS serving_cell BSC MSC BSC target_cell MSTCH request queued <------ASSIGNT REQUEST-------

EDR condition met ------ HO_REQUIRED ---------->MC144F ----------CR (HO_REQUEST) -----> MC820

<--------- CC ------------------------ ---- CHANNEL_ACTIVATION ------><- CHANNEL_ACT_ACK-------------

<----- HO_REQUEST_ACK -------- Start T9113(HO_COMMAND) MC821

<------------------------- HO_COMMAND ------------------------------------------------------ <---- HO_ACCESS -----C145B+C145D Start T8 <---- HO_ACCESS -----

<------ HO_DETECTION--------------<-- HO_DETECTION -------------- --- PHYSICAL_INFO -->



<---- CLEAR_COMMAND ------ MC642MC142F Cause : HO_SUCCESSFUL

Release of SDCCH Stop T8

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 HOsin the related counters.






Outgoing External DR - Failures

DR FAIL. CASES > Outgoing external DR failuresDirected 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: radio problem: the MS reverts to the old channelradio problem: the MS dropsBSS problem (no specific counter)






Outgoing External DR - Radio Failure ROC

DR FAIL. CASES > Outgoing external DR fail: reversion old channel

C145B,C143C: Forced DRC145D,C143G: Normal DR

MS serving_cell BSC MSC BSC target_cell MSASSIGNT REQUEST---------------------> TCH request queued

EDR condition met ---- HO_REQUIRED ------->MC144F ----------CR (HO_REQUEST) ------------------->

<-------- CC --------------------------------------- - CHANNEL_ACT ----------><--- CHA_ACT_ACK --------

<----- HO_REQUEST_ACK----------------------- Start T9113 (HO-COMMAND) included


C145B+C145D X ---- HO_ACCESS ---------- SABM --------><--- UA ------------- -- ESTABLISH_INDICATION->

----- HO_FAILURE (reversion to old channel) ------------------------------------------>C143C+C143G ----- CLEAR_COMMAND ---------------------->

Radio interface fail : Reversion to old channelRelease of connection






Outgoing External DR - Radio Failure Drop

DR FAIL. CASES > Outgoing external DR fail: drop

C145B,C143D: Forced DRC145D,C143H: Normal DR

MS serving_cell BSC MSC BSC target_cell MSASSIGNT REQUEST---------------------> TCH request queued

EDR condition met ---- HO_REQUIRED ------->MC144F ----------CR (HO_REQUEST) ------------------->

<-------- CC --------------------------------------- - CHANNEL_ACT ----------><--- CHA_ACT_ACK --------

<----- HO_REQUEST_ACK----------------------- Start T9113 (HO-COMMAND) included


C145B+C145D X ---- HO_ACCESS ---------- SABM --- X----- SABM --- X

----- SABM --- X

T8 expiry ----- CLEAR_REQUEST ->C143D+C143H Radio interface message fail







Outgoing External DR - Counters

DR FAIL. CASES > Outgoing external DR counters

Preparation Request MC144F, C144B+C144D

Any preparation failure (C144B+C144D) - (C145B+C145D)

Attempt C145B+C145D

Reversion old channel C143C+C143GDrop radio C143D+C143HBSS Pb (C145+C145D) - (C143C+C143G+C143D+C143H)

Success MC142F, C142B+C142D

Execution

OUTGOING EXTERNAL Directed Retry

REQUEST

CONGESTION

ATTEMPT


DROP RADIO

BSS PB

SUCCESS

BSS PB

Preparation Failure

Execution Failure




Specific indicators for densification techniques > Directed Retry > Outgoing DR

DROMSUR: global efficiency of outgoing external DR = MC142F/MC144F

Other indicators can be computed


efficiency of the outgoing internal DR preparation = (C145B+C145D)/(C144B+C144D)

efficiency of the outgoing internal DR execution = (C142B+C142D)/(C145B+C145D)

rate of outgoing internal DR execution failures due to BSS problems = [(C145B+C145D) - (C143C+C143G+C143D+C143H)] / (C145B+C145D)

rate of outgoing internal DR execution failures due to radio problems with reversion old channel = (C143C+C143G) / (C145B+C145D)

rate of outgoing internal DR execution failures due to radio problems with drop = (C143D+C143H) / (C145B+C145D)

Interesting indicator:

TCQUSUDSR: rate of outgoing internal and external directed retries (forced + normal) successfully performed over all RTCH requests queued during normal assignment.





4 GSM BSS Protocol Stacks






Signaling Links

A-Interface MT-Link signaling #7 System with SCCPMSC BSC

BSC BTSAbis Interface RSL with LAPD Protocol

BTS MSAir-Interface (CCCH/SACCH/FACCH) with LAPDm Protocol

BSC OMC-ROML Link with X25 connection LAPB Protocol






The Reference Model

7 Application

6 Presentation

4 Transport

5 Session

2 Data Link

3 Network

1 Physical

User of Transport Service

Transport ServiceNetworkService






The Reference Model [cont.]

Layer 1Physical; Responsible for the transparent transmission of information across the physical medium (HDB3, PCM, AMI)

Layer 2Data Link; Responsible for providing a reliable transfer between the terminal and the network (#7, LAPD,etc.)

Layer 3Network; responsible for setting up and maintaining the connection across a network (CM, MM, RR, Message routing, etc.)






The Reference Model [cont.]

Layer 4Transport; responsible for the control of quality of service (Layer of information)

Layer 5Session; Handles the coordination between the user processes (Set up transfer of information)

Layer 6Presentation; responsible for ensuring that the information is presented to the eventual user in a meaningful way (Type format. Ex. ASCII)

Layer 7Application; provides lower levels with user interface (Operating System)






BSS Protocol Stacks

BTS PSTNISDN

Air Intfc Abis Intfc A Intfc B .. F Intfc

MS BSC MSC

CM

MM

RR

LAPDm

digit

radio

RR BSSAP

LAPDm LAPD

digit

radio64 kb/s 64 kb/s 64 kb/s 64 kb/s

LAPD

RR

BTSM

BSSAP

CM

MM

BSSAP

SCCP

MTP

SCCP

MTP LAYER 2

LAYER 1

LAYER 3






BSS Protocol Stacks [cont.]

(detailed)

SSCS

SSTM 3

SSTM 2

SSCS

SSTM 3

SSTM 2

SSGT

MAP

SSGT

MAP

SSCS

SSTM 3

SSTM 2

PCM TS

DTAP

SSCS

SSTM 3

SSTM 2

PCM TS

DTAP

LAPDLAPDm LAPD

SS (SMS)SS (SMS)

BSSMAP

MM

CC

BSSMAPRR

RR

RR' BTSMBTSM

LAPDm

(SMS)SSCC

MM

(Relay)

MS BTS BSC MSC / VLR NSS(ex. : HLR)

Um A bis A (D)1

2

3

(Relay

64 kbit/sor PCM TS

64 kbit/sor PCM TS PCM TS PCM TSPhycal

LayerPhycalLayer






Signaling on the A Interface

Uses #7 with Signaling Connection Control Part (SCCP) with a newApplication Base Station Application Part (BSSAP). BSSAP is divided into Direct Transfer Application Part (DTAP) and Base Station Subsystem Management Application Part (BSSMAP)

DTAP

BSSMAP

SCCP

MTP 1-3

User Data

Layer 1-3

BSSAP






GSM BSS Protocols

BSSMAPContains the messages, which are exchanged between the BSC and the MSC and which are evaluated from the BSCIn 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 BSCExample: Paging, HND_CMD, Reset

DTAPMessages 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)






GSM BSS Protocols [cont.]

Relationship between DTAP, CC, MM, BSSMAP, RR

MSBSS MSC

Call Control (CC) DTAP

Radio Resource (RR)BSSMAP

Back





5 LCS





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) GPSAssisted GPS (with the help of A-GPS server to compute location)

MS based (MB): MS is able to perform a pre-computationMS assisted (MA): MS sends info, Network computes

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.

WithOTD: 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+ TAConventional (MS equipped with GPS System)A-GPS MS BasedA-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

SMLCBTS

BTS

MS

BSC

MSC

HLR

GMLC

OSP

Lg

Lh

ExternalLCS client

LeA

Abis

Abis

Lb

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

MFS

A-GPS server

SAGI

GPS reference network

LCS: Location ServicesSMLC: Serving Mobile Location CenterGMLC: Gateway Mobile Location CenterA-GPS: Assisted GPS

Where is my son?

Where is the accident? Emergency call

2

Where am I?

1

3

MS Request

Network Request

External Request3

2

1

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)SMLCMS BSCBTS LCS ClientMSC

BSSAP-LE Perform_Location_Request

.

GMLC

BSSMAP Perform_Location_Request

BSSAP-LE Perform_Location_Response

BSSMAP Perform_Location_Response

BSSMAP Clear Command and Release

Adequat positionning method chosen by SMLC

HLR

Paging

Authentication + Ciphering

LCS Service Response

LCS Service Request

Send_Routing_Info rqst

Send_Routing_Info resp

Provide_Subscriber_Location

Provide_Subscriber_Location Result

MC923a

MC923b

MC923d

MC923cBSSAP-LE Perform_Location_Response (failure)

BSSMAP Perform_Location_Response (failure)

BSSMAP Perform_Location_Abort

Failure

Success

Four counters

MC923a NB_LCS_REQ Number of location requests received from the MSC in CS domain.

MC923b NB_LCS_SUCC Number of successful location requests performed in a BSS.

MC923c NB_LCS_FAIL_LB Number of location requests rejected by the SMLC.

MC923d NB_LCS_ABORT Number of location aborts received from the MSC in CS domain.

Calculated indicators based on BSC counters:

Number of failures on LCS requests due to BSS problem,

Rate of LCS requests aborted,

Rate of successes on LCS requests,

Rate of failures on LCS requests,

Rate of SDCCH seizures for Location Services.

Other counters in SMLC (MFS) provide details by type of positioning (CI+TA, Conventional GPS, MS-Assisted A-GPS, MS-Based A-GPS) and for different Error causes.

See the next slide.



LCS Counters in MFS: QOS FOLLOW UP:

P800: NB_LOC_REQ Number of received LCS requests for MS positioning received from the BSC

P801: NB_ASSIST_DATA_REQ Number of received LCS requests for GPS assistance data (initially requested by the MS) received from the BSC.

P802: NB_ASSIST_DATA_SUCC Number of successful GPS assistance data delivery (initially requested by the MS) responses sent to the BSC.

P803: NB_LOC_TA_SUCC Number of successful location responses sent to the BSC using TApositioning method.

P804: NB_LOC_CONV_GPS_SUCC Number of successful location responses sent to the BSC using Conventional GPS positioning method.

P805: NB_LOC_MA_AGPS_SUCC Number of successful location responses sent to the BSC using MS-Assisted A-GPS positioning method.

P806: NB_LOC_MB_AGPS_SUCC Number of successful location response sent to the BSC using MS-Based A-GPS positioning method.

P807: NB_LOC_TA_PCF_REQ Number of location calculation attempts with TA positioning PCF.P808: NB_LOC_TA_PCF_SUCC Number of location calculations successfully performed with TA

positioning PCF.P809: NB_LOC_CONV_GPS_PCF_REQ Number of location calculation attempts with Conventional GPS PCF.P810: NB_LOC_MA_AGPS_PCF_REQ Number of location calculation attempts with MS-Assisted A-GPS PCF.P811: NB_LOC_MA_AGPS_PCF_SUCC Number of location calculations successfully performed with MS

Assisted A-GPS PCF.P812: NB_LOC_MB_AGPS_PCF_REQ Number of location calculation attempts with MS-Based A-GPS PCF.P813: NB_LOC_MB_AGPS_PCF_SUCC Number of location calculations successfully performed with MS-Based

A-GPS.P814: NB_LCS_PROTOCOL_ERROR Number of failed LCS procedures due to LCS protocol error.P815: NB_LCS_INTERRUPTED_INTRA_BSC_HO Number of failed LCS procedures due to intra-BSC handover.P816: NB_LCS_INTERRUPTED_INTER_BSC_HO Number of failed LCS procedures due to inter-BSC handover.P817: NB_LCS_FAILURE_RRLP Number of failed LCS procedures due to RRLP problem.P818: NB_LCS_FAILURE_TIMER_EXPIRY Number of failed LCS procedures due to LCS guard timer expiry.P819: NB_LCS_FAILURE_INTERNAL Number of failed LCS procedures due internal problem detected by

the MFS/SMLC.P820: NB_UNKNOWN_LCS_REQ Number of LCS requests rejected because not supported by the SMLC.P821: NB_LOC_CONV_GPS_PCF_SUCC Number of location calculations successfully performed with Conventional GPS PCF.



PCF: Positioning Calculation FunctionPOSITION AVERAGE USED ON RNO: Values are given in minutes

LATITUDES AND LONGITUDES: P822: AV_TA_LAT Average of latitudes for TA MethodP823: AV_TA_LONG Average of longitudes for TA MethodP824: AV_CONV_GPS_LAT Average of latitudes for Conventional GPS MethodP825: AV_CONV_GPS_LONG Average of latitudes for Conventional GPS MethodP826: AV_MA_AGPS_LAT Average of latitudes for MS-Assisted A-GPS MethodP827: AV_MA_AGPS_LONG Average of longitudes for MS-Assisted A-GPS MethodP828: AV_MB_AGPS_LAT Average of latitudes for MS-Assisted A-GPS MethodP829: AV_MB_AGPS_LONG Average of longitudes for MS-Based A-GPS Method

STANDARD DEVIATION: standard deviation is a measure of the dispersion around the average point

P830: ST_DEV_TA_LAT Standard deviation of the latitude of MS obtained with TA MethodP831: ST_DEV_TA_LONG Standard deviation of the longitude of MS obtained with TA MethodP832: ST_DEV_CONV_GPS_LAT Standard deviation of the latitude of MS obtained with Conventional

GPS MethodP833: ST_DEV_CONV_GPS_LONG Standard deviation of the longitude of MS obtained with

Conventional GPS MethodP834: ST_DEV_MA_AGPS_LAT Standard deviation of the latitude of MS obtained with MS Assisted

A-GPS MethodP835: ST_DEV_MA_AGPS_LONG Standard deviation of the longitude of MS obtained with MS Assisted

A-GPS MethodP836: ST_DEV_MB_AGPS_LAT Standard deviation of the latitude of MS obtained with MS Assisted

A-GPS MethodP837: ST_DEV_MB_AGPS_LONG Standard deviation of the longitude of MS obtained with MS Assisted

A-GPS Method





5 LCS

Definitions

New end-user services which provide the geographical location of an MS:

On MS request to know its own location On network request (especially during Emergency calls)On external request (LCS Client)

Several positioning methods:Cell-ID or Cell-ID + TA (Timing Advance)Conventional (standalone) GPSAssisted GPS (with A-GPS server help to compute location)

MS-based (MB): the MS is able to perform a pre-computationMS-assisted (MA): the MS sends info, Network computes

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’s location estimate.

WithOTD: 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

MS Request1Network Request2External Request3

A-GPSGMLCLCSSMLC

: Assisted GPS: Gateway Mobile Location Center: Location Services: Serving Mobile Location Center

BTS

Abis

MFS

BTS

OSP

SMLC

A-GPSserver

GPS receiversreference network

GMLC ExternalLCS client

MSCBSC

HLR

Abis

A Lg Le

Lh

Lb

Emergency call

2 3

SAGI

Where isthe accident?

Where ismy son?

Where am I?

1

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





5 LCS

LCS Positioning Procedure

BTS

MFS

BTS

OSP

SMLC

GMLCMSC

BSC

HLR

Locationrequest

1

Routinginformation

2

Providesubscriber

location3

Paging,authentication,

ciphering,notification

4

Providesubscriber location

5

Individualpositioning

6 Location report7 7Locationresponse

8

If the MS is in idle mode, the MSC first performs a CS paging, authentication and ciphering in order to establish an SDCCH with the MS. The MS subscriber is not aware of it, i.e. no ringing tone, except towards GPRS MS in Packet Transfer Mode which may suspend its GPRS traffic in order to answer to the CS Paging (i.e. not fully transparent for the subscriber).

When the MS is in dedicated mode (after a specific SDCCH establishment for location, or during an on-going call), the MSC sends the location request to BSC in the existing SCCP connection for the current call, which forwards it to the SMLC.





5 LCS

LCS Protocol

BSC SMLC(MFS)

Um Lb

L1-GSL

L2-GSL

BSSLAP

L2-GSL

BSSAP-LE

L1-GSLL1

L2(LAPDm)

RR

Relay

RRLP(04.31)

BSSLAP(08.71)

BSSAP-LE(09.31)

Target MS

L1

RR(04.18)

L2(LAPDm)

RRLP(04.31)

Signaling Protocols between the MS (CS domain) and the SMLC





5 LCS

LCS Protocol [cont.]

Example: Mobile terminated location request success (External request)MS BTS BSC SMLC MSC GMLC HLR

Adequate positioning methodchosen by SMLC with

optional additional scenario

StartsT_Location

StopT_Location

LCS Service Request

Send_Routing_Info request

Send_Routing_Info response






BSSMAP Perform_Location_Response

Provide_Subscriber_Location Result

LCS Service Response

MSSMAP Clear Command and Release

LCS client

Paging

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_abortto 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_LONGITUDE

LCS_LATITUDE

LCS_AZIMUTH(Main Beam Directiongiven by the azimuth)

HALFPWR_BEAM_WIDTH

Serving cell (CI)

TA

3dB pointgiven by the azimuth

and the HPBW

3dB pointgiven by the azimuth

and the HPBW

553 m

MSestimated location

With the TA positioning method, no signaling exchange is required between the SMLC and the MS (i.e. RRLP protocol is not required). The TA positioning method is applicable to all the MSs (supporting LCS or not).

Based on:

Cell Identity (CI) of the serving cell.

Timing Advance (TA) value reported by MS:

intersection point of a line from the BTS antenna in their main direction with a circle which radius is corresponding with the propagation delay (timing advance) is the MS estimated position.Omni-directional cells: MS position = site position.

Parameters:

EN_LCS – flag to enable/disable the Location Services per BSS

0 = Enabled; 1= Disabled; Default = 0

IF EN_LCS=1, CI+TA method is enabled in all the BSS cells

LCS_LATITUDE: Latitude of the BTS supporting the cell

LCS_LONGITUDE: Longitude of the BTS supporting the cell

LCS_AZIMUTH: Antenna direction orientation for the sector supporting the cell

HALFPWR_BEAM_WIDTH: Antenna half power beamwidth for the sector supporting the cell

Optimization parameters:ARC_SIZE_FACTOR: Factor used in the computation of the width in degree of the ellipsoid arc returned by the MFS when

computing location estimate based on TA positioning method. MIN_RADIUS_FACTOR: Factor used in the computation of the minimum radius of the ellipsoid arc returned by the MFS

when computing location estimate based on TA positioning method MAX_RADIUS_FACTOR :Factor used in the computation of the maximum radius of the ellipsoid arc returned by the MFS

when computing location estimate based on TA positioning method





5 LCS

Positioning Methods: Conventional GPS

Conventional GPS location procedureThis optional location procedure is chosen by the SMLC (if the MS supports it) upon reception of a Perform Location Request message from the BSC

PerformLocationRequest

MS BTS BSC SMLC

Measurement Position Request

Measurement Position Response (X,Y)

PerformLocation

Response (X,Y)(X,Y):

computed position

(X,Y)

LocationRequest

LocationResponse

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 methodMS Assisted A-GPS method

- GPS acquisition assistance- Navigation model (almanac, ephemeris)- Ionospheric model- Time integrity

GPS MS A-GPSserver

GPS receiversreference network

Assistance data on request

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

LocationRequest

A-GPSServer

GPS infoRequest

GPS infoResponse


Assistance Data

Assistance Data Acknowledge

Measurement Position Response (X,Y)

PerformLocation

Response (X,Y)

LocationResponse

PositionRequest

PositionResponse

AssistanceData

(X,Y)

(X,Y):computed position

Positioning calculation:latitude, longitude

and altitude

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

(X,Y):computed position

Pseudo-rangemeasurements (M)

PositionResponse


MS BTS BSC SMLC

LocationRequest

A-GPSServer

GPS infoRequest

GPS infoResponse


Assistance Data

Assistance Data Acknowledge

PerformLocation

Response (X,Y)

LocationResponse

PositionRequest

AssistanceData

(X,Y)

Measurement Position Response (M)

GPS LocationRequest (M)

GPS LocationResponse (X,Y)

Using a reduced set of assistance data, the MS makes pseudo–range measurements and sends the result to the A-GPS server, which fixes the position in the end.





5 LCS

LCS Impact on HO

HO preparationInhibition of “better cell handovers”Other HO

MS BTS BSC SMLC MSC GMLC HLR

StartsT_Location

EmergencyHO

detection

LCS Service Request

Send_Routing_Info request

Send_Routing_Info response





LCS client

Paging

BSSLAP - Reset

HO needed during LCS procedure.





5 LCS

LCS Impact on HO [cont.]

HO managementInternal HO

MS BTS BSC SMLC MSC GMLC HLR

HOcomplete



LCS client

BSSLAP - Reset

Intra BSCHO

on going

BSSMAP perform location response (cause = "Intra-BSC Handover Complete)

Mobile in communication





5 LCS

LCS Impact on HO [cont.]

HO managementExternal HO

MS BTS Serving BSC SMLC MSC GMLC HLR

ExternalBSC HO

BSSAP-LE Perform_Location_Abort

LCS client


BSSMAP HO required






5 LCS

BSS Parameters

Timers

T_LocationT_Location_longerT_Loc_AbortT_LCS_delay_tolerantT_LCS_LowDelayT_RRLP_low_delayT_RRLP_delay_tolerant

FLAGS

EN_LCSEN_SAGI

OPTIMIZATION DATA

ARC_SIZE_FACTORMIN_RADIUS_FACTORMAX_RADIUS_FACTOR

BSS PARAMETERSEN_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

SITE DATA

LCS_LATITUDELCS_LONGITUDELCS_SIGNIFICANT_GCLCS_AZIMUTHHALF_POWER_BANDWIDTH

EN_CONV_GPSEN_MS_ASSISTED_AGPSEN_MS_BASED_AGPS

FLAGS

CELL PARAMETERSEN_CONV_GPS: Flag to enable/disable the Conventional GPS positioning method.

EN_MS_ASSISTED_AGPS: Flag to enable/disable the MS Assisted A-GPS positioning method.

EN_MS_BASED_AGPS: Flag to enable/disable the MS Based A-GPS positioning method.

LCS_LATITUDE: Latitude of the BTS supporting the cell (used by the MFS to compute location estimate based on TA positioning method).

LCS_LONGITUDE: Longitude of the BTS supporting the cell (used by the MFS to compute location estimate based on TA positioning method).

LCS_SIGNIFICANT_GC: Indicates whether latitude and longitude are significant or not

LCS_AZIMUTH: Antenna direction orientation for the sector supporting the cell (used by the MFS to compute location estimate based on TA positioning method).

HALF_POWER_BANDWIDTH: Half power beam width of the antenna for the sector supporting the cell (used by the MFS to compute location estimate based on TA positioning method).

Remark: To have LCS supported for a cell, the operator must activate LCS on the BSS handling this cell but he must also activate GPRS for this cell (i.e. setting of MAX_PDCH to a value > 0, the cell being kept locked for GPRS if the operator does not want to have GPRS running on this cell) and configure all the required transmission resources (Ater and Gb resources) on the GPU(s) connected to this BSC.





5 LCS

Exercise

Where is implemented the SMLC function?What are the LCS impacts on cell dimensioning?

Time allowed: 10 minutes





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 anglesof co-sited antenna azimuthsr1= inner radius ofTA ring-(B-0.5)*554 in [m]R2=(B+C)*554 in [m]

A: ARC_SIZE_FACTORB: MIN_RADIUS_FACTORC: MAX_RADIUS_FACTOR

Back

Serving cell (CI)

E

North

S

W β

θ

r1

r2

Point (O)

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,000…1° 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)






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

BSC

BTS

OMC-R






Characteristics of the Feature [cont.]

GSM antennas are widely in living and working placesLack of information provided to people on their exposure to EM fields and the risks they are runningPeople concerned about their health, risk of complaints

Some European directives/recommendations are already applicable or will be very soon






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 typeNew Type: Type 33Permanent type (PMC) with a fixed accumulation period: 1 hourCounters available in MPM and NPA

Back

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





7 B8 Improvements

Summary

Location Services (LCS)SDDCH Dynamic allocationCounters Improvement

Inter PLMN HO3G to 2G HO (and 2G to 2G only)Dual band HO (New type: 32)LapD congestion counterQOS Follow-up

TCH assignment failure BSS PB now detailedHO Attempts for Fast Traffic added in type 110AMR counters added in type 110MS penetration (per speech version and channel type) was type 1 counters now available in type 110HO Causes: type 26 extended from 1 to 40 cellsDirected retry: type 29 becomes a standard (for PMC)





8 B9 Improvements





8 B9 Improvements

Summary

Type 31: New RMS countersFor AMR monitoringFor Timing Advance analysisFor 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





9 Dynamic SDCCH Allocation






Purpose

SDCCH/8 time slots can be dynamically allocated on demand on a cell-by-cell basis.

“Dynamic SDCCH/8 time slots”. “Static SDCCH time slots”

Min

Max

Static SDCCHtimeslots

AllocatedDynamic SDCCH/8

timeslots

0

TCH Capacity

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

PrinciplesToo 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)

SDCCHtime slots

TCH CAPACITY

SDCCHtime slots

TCH CapacityTCH Capacity

Configuration 1 Configuration 2

Low signaling capacity

More TCH capacity

High signaling capacity

Less TCH capacity

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

BCC SDC TCH TCH

TCH TCH TCH TCH

TCH TCH TCH TCH

TCH TCH TCH TCH

TCH TCH TCH TCH TCH TCH TCH TCHCell

Allocation ofDynamic SDCCH/8

times slots

BCC SDC

SDD TCH

TCH TCH

BCC SDC

SDD TCH

SDD TCH

BCCSDCSDD

: BCCH: Static SDCCH: Dynamic SDCCH

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 TCHTCH/SDCCH “ dynamic SDCCH”TCH/SPDCH

MPDCH

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

Are they any free SDCCH sub-channelamong Static SDCCH timeslots?

Selection of oneSDCCH sub-channel

Yes No

Are they any free SDCCH sub-channelamong Dynamic SDCCH/8 already allocated?

Selection oneSDCCH sub-channel

Yes

Are they any Dynamic SDCCH/8 timeslotsavailable and free in the cell?

No

Allocate one DynamicSDCCH/8 timeslot

Yes No

SDCCH Requestrejected!!!

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 TimeslotTS with LOWEST TCU LOADTS with MAXIMUM FREE SDCCH Sub channelsTS with lowest index on TRX with lowest TRX_ID

TCH/SDCCH TS allocated as SDCCHTS on FR TRXTS with lowest index on TRX with lowest TRX_ID

TCH/SDCCH TS allocated as TCHTS with LOWEST TCU LOADTS on FR TRXTS with lowest index on TRX with lowest TRX_ID

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 SDCCHone 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 one’s 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)

The de-allocation algorithm ensures that:

TCH/SDCCH timeslots are not allocated too fast to TCH after de-allocating them

TCH/SDCCH timeslots are not re-allocated too frequently to SDCCH

Note: while T_DYN_SDCCH_HOLD is running:

the dynamic SDCCH/8 timeslot marked as “HOLD” is still considered as allocated to SDCCH (and can not be allocated to TCH);

if a subsequent dynamic SDCCH/8 timeslot (used as SDCCH and in the same cell) becomes free:

a) If this just freed dynamic SDCCH/8 timeslot has a higher priority, T_DYN_SDCCH_HOLD is re-started and precedent dynamic SDCCH/8 timeslot in “HOLD” state is de-allocated immediately;

b) If this just freed dynamic SDCCH/8 timeslot has lower priority, and T_DYN_SDCCH_HOLD is re-started and the just freed dynamic SDCCH/8 timeslot is de-allocated immediately.






O&M Configuration

Massive modification by script

10 templates Template customizationTemplate launched through PRC

Selection of static or dynamic SDCCH

Timeslot configuration menu

BTS

BTS

BTS

BTS

2

4

7

3

1

10

9

6

12

8

5

11

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 cannothave 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 TRXin the cell

Number ofStatic SDCCH

Number ofDynamic SDCCH

Total numberof SDCCH

MaximumSDCCH/TRX

ratio

Is BCCH/CCCHcombined with

SDCCH?

1223456789

10111213141516

4488888

16161616161616242424

88

161624242424243232324040404848

1212242432323240404848485656647272

12.0 (note 1)6.0

12.08.08.06.45.35.75.05.34.84.44.74.34.64.84.5

YesYesNoNoNoNoNoNoNoNoNoNoNoNoNoNoNo

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).

RulesAt 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





Emergency handovers specific to concentric cellsIntracell handovers from inner to outer zonecause 10: too low level on the uplink in inner zonecause 11: too low level on the downlink in inner zone

May be triggeredFrom inner zone of a concentric cellTowards outer zone, same cell


Algorithms

Concentric cellI n n e r z o n e

Outer zone





CAUSE 10: too low level on the uplink in the inner zone

AV_RXLEV_UL_HO < RXLEV_UL_ZONEand MS_TXPWR = min (P, MS_TXPWR_MAX_INNER)

Averaging window: A_LEV_HO


Handover Algorithm Cause 10





CAUSE 11: too low level on the downlink in the inner zone

AV_RXLEV_DL_HO < RXLEV_DL_ZONEand BS_TXPWR = BS_TXPWR_MAX_INNER

Averaging window: A_LEV_HO


Handover Algorithm Cause 11





CAUSE 13: too high level on UL and DL in the outer zoneBetter condition intracell handoverIf the cell is a multi-band cell, cause 13 is checked only for multi-band MSs

May be triggeredFrom outer zone of a concentric cellTowards inner zone, same cell


Handover Algorithms Cause 13

Concentric cellI n n e r z o n e

Outer zone





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) +

+ PING_PONG_MARGIN(0,call_ref)and AV_RXLEV_DL_HO > RXLEV_DL_ZONE +

+ ZONE_HO_HYST_DL ++ (BS_TXPWR - BS_TXPWR_MAX_INNER) ++ PING_PONG_MARGIN(0,call_ref)

and AV_RXLEV_NCELL_BIS(n) <= neighbour_RXLEV(0,n)and EN_CAUSE_13 = ENABLE (B7)and EN_BETTER_ZONE_HO = ENABLE

Averaging windows: A_LEV_HO and A_PBGT_HO (for n)


Handover Algorithms Cause 13 [cont.]





ZONE_HO_HYST_ULUL 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_DLDL 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







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 cellAnd the last handover was not external intracellAnd T_HCP is still running

PING_PONG_MARGIN(0,call_ref) = 0If the call was not previously in the serving inner zoneOr T_HCP has expired



Concentric cell

I n n e r z o n e

Outer zone





neighbour_RXLEV(0,n)

Concentric cells are designed to create an INNER zoneprotected from external interferersand 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 interferencesthe condition is checked towards all neighbor cells belonging to the same layer and band as the serving cell



Concentric cellOuter zone

?

Inner zoneinterferer 1

Inner zoneinterferer 2Inner zone





EN_CAUSE_13Load balance between inner and outer zones may be allowed by setting EN_LOAD_BALANCE = ENABLE

If EN_LOAD_BALANCE = ENABLEIf INNER zone is less loaded than OUTER,EN_CAUSE_13 = ENABLEIf INNER zone is more loaded than OUTER,EN_CAUSE_13 = DISABLE

If EN_LOAD_BALANCE = DISABLEEN_CAUSE_13 = ENABLE







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

For example, an MS locatedin the INNER zone of aconcentric cell can makedirectly an HO cause 12towards another cell,WITHOUT having totrigger any cause 10 or 11to the OUTER zone before


Outgoing Intercell Handovers from Concentric Cell


Inner zone


Inner zone


Inner zone

The only restrictions are linked to EN_MULTI-BAND_PBGT_HO and EN_BI-BAND_MS parameters.





Incoming intercell handovers towards a concentric cellIn 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 setupdepending 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


Incoming Intercell Handovers towards Concentric Cell


Inner zone

Cell

??





Use part of Handover cause 13 algorithm on each potential targetIF Cell(n) is external

The MS is directed to the OUTER zone of (n)ELSE (cell(n) is internal)

IFAV_RXLEV_NCELL(n) > RXLEV_DL_ZONE + ZONE_HO_HYST_DL +

+ (BS_TXPWR - BS_TXPWR_MAX_INNER)and EN_BETTER_ZONE_HO = ENABLE

The MS is directed towards the INNER zone

ELSEThe MS is directed towards the OUTER zone


Incoming Intercell Handovers towards Concentric Cell [cont.]





End of ModuleAnnexes

B10_GSM_QoS and Traffic Load

Documents

Transcript of B10_GSM_QoS and Traffic Load