3FL10491ADAAWBZZA_02

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

All Rights Reserved © Alcatel-Lucent 2010


EVOLIUM Base Station Subsystem

BSS B10 Introduction to Quality of Service and Traffic Load

Monitoring

STUDENT GUIDE

3FL10491ADAAWBZZA2 Issue 2

All rights reserved © Alcatel-Lucent 2010 Passing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent




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

2

Empty page

Switch to notes view!

This page is left blank intentionally





3

Terms of Use and Legal Notices

Switch to notes view!1. Safety Warning

Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to

wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the

equipment alone.

The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.

2. Trade Marks

Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.

All other trademarks, service marks and logos (“Marks”) are the property of their respective holders, including Alcatel-

Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning

the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.

Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to

change without notice.

3. Copyright

This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No

other use or transmission of all or any part of this document is permitted without Alcatel-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 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.

All rights reserved © Alcatel-Lucent 2010

4. Disclaimer

In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including

lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel-

Lucent has been advised of the possibility of such damages.

Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an

endorsement, nor a recommendation.

This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The

information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some

cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely

accurate.

Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment

and its operation, or contact your nearest Alcatel-Lucent representative for more information.

The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-

Lucent disclaims any warranties in connection with the products as used and described in the courses or the related

documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,

including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of

dealing, usage or trade practice.

Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed

internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in

nature

5. Governing Law

The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are

governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal

Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,

but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a

valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these

Terms of Use and Legal Notices shall remain in full force and effect.





4

Blank Page







5

Course Outline

About This CourseCourse outline

Technical support

Course objectives

1. Topic/Section is Positioned HereXxx

Xxx

Xxx

2. Topic/Section is Positioned Here






1. GSM QoS Monitoring

1. Introduction 3JK11043AAAAWBZZA

2. Global Indicators 3JK11044AAAAWBZZA

3. Detailed Indicators 3JK11045AAAAWBZZA

4. Handover Indicators 3JK11046AAAAWBZZA

5. Directed Retry Indicators 3JK11047AAAAWBZZA

6. Radio Measurement Statistics Indicators 3JK11048AAAAWBZZA

7. Traffic Indicators 3JK11049AAAAWBZZA

8. Case Studies 3JK11050AAAAWBZZA

9. Annexes 3JK11051AAAAWBZ





6

Course Outline [cont.]







7

Course Objectives


Welcome to BSS B10 Introduction to Quality of Service and Traffic Load

Monitoring

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

� Global indicators, in order to assess the general quality of the network

� Detailed indicators, in order to detect / identify / locate the main malfunctions

� Handover indicators, in order to quantify efficiency and reason of HO

� Directed retry indicators, in order to quantify efficiency of directed retry

� RMS indicators to ease radio optimisation and fault detection

� Traffic indicators, in order to detect/predict overload and compute adequate cell

dimensioning as well as to understand how RTCH resources are used in the network





8

Course Objectives [cont.]







9

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.





10

About this Student Guide [cont.]

� Switch to notes view!






11

Self-assessment of Objectives

� At the end of each section you will be asked to fill this questionnaire

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


Instructional objectives Yes (or globally yes)

No (or globally no)

Comments

1 To be able to XXX

2

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

��





12

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

��

Section 1 � Module 1 � Page 1


3JK11043AAAAWBZZA Issue 01

Do not delete this graphic elements in here:

1�1All Rights Reserved © Alcatel-Lucent 2010

Module 1Introduction


Section 1GSM QoS Monitoring

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






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

1 � 1 � 2

Blank Page


First edition, B11 MR1Xavier Pourtauborde29-June-201001

RemarksAuthorDateEdition

Document History






1 � 1 � 3

Module Objectives

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

� Explain what is QoS and Traffic Load monitoring of the BSS

� Explain what are the information sources available for that purpose






1 � 1 � 4

Module Objectives [cont.]







1 � 1 � 5

Table of Contents

Switch to notes view!Page

1 Monitoring the QoS of the BSS 7Definition 8Scope of Work 9

2 Monitoring the Traffic Load of the BSS 10Definition 11

3 Information Sources Available 12Observation Tools 13Interface Trace 16Example of Abis & A Traces 17Example of Traces Post-Processing 18Example of Drive-Test 20Performance Measurement Counters 21Exercise 22Alcatel-Lucent BSS Counters 23BSS Counter Example 24Exercise 26

4 Introduction to K1205 PC Emulation 27Usage 28Measurement Scenarios Screen 29Filter Configuration 30Monitor Screen 31Extract a Call 32Call Extraction 33Exercise 34

5 Indicators Definition 35BSS Indicators Definition (Alcatel-Lucent) 36Typical KPI for BSS 37Typical KPI for Drive-tests 38Typical Thresholds 39Typical KPI Report 40

6 Methodological Precautions 41Objective 42Network Element Aggregation 43Global Indicator Validity 44Time Period Aggregation 45Exercise 46Self-assessment on the Objectives 47End of Module 48






1 � 1 � 6

Table of Contents [cont.]








1 � 1 � 7

1 Monitoring the QoS of the BSS






1 � 1 � 8


Definition

� "Monitor" "network" "quality"

� monitor = measure or ensure?

� network = BSS? BSS+NSS? BSS+NSS+PSTN …

� quality = service (end-user) and/or system (technical)

� But also detect, localize, diagnose outages

� detect (decide according to thresholds)

� localize (which cell, BSC, etc.)

� diagnose: radio, BSS, TC problems






1 � 1 � 9


Scope of Work

� Use all available tools at disposal to ensure:

� Subscribers get good QoS

� BSS equipments & interfaces are all running efficiently (no alarms, no critical situation)

� BSS Optimizers receive good inputs to enhance the network

� Management can characterize the network and deploy operational teams accordingly






1 � 1 � 10

2 Monitoring the Traffic Load of the BSS






1 � 1 � 11

2 Monitoring the Traffic Load of the BSS

Definition

� Measure the "quantity" of traffic handled by:

� each equipment, each board

� each interface

� Analyze traffic characteristics

� call, handover, location update, etc.

� As input for dimensioning/architecture team

MSC/VLR GGSN

BTSBSC

BTS

BTSBSC

Circuit CoreNetwork

IPNetwork

GPRSbackbone

SGSNMFS






1 � 1 � 12

3 Information Sources Available






1 � 1 � 13


Observation Tools

� System Performances: OMC-R PM (Performance Measurements) Counters

MSC/VLRGGSN

BTS BSC

BTS

BTS

BSC

Circuit CoreNetwork

IPNetwork

GPRSbackbone

SGSNMFS

OMC-R NPO

GSM PM Files are located in the OMC-R: /alcatel/share/var/AFTR/APME/BSC

cf. PM file snapshot in the comments

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

9159 NPO: Network Performance Optimizer, replace NPA + RNO since B10 onwards.

Extract from a PM File in OBSYNT format, from 17:00 to 17:30.






1 � 1 � 14


Observation Tools [cont.]

� NSS Performance: Core Network Counters

MSC/VLRGGSN

BTS BSC

BTS

BTSBSC

Circuit Core

Network

IPNetwork

GPRSbackbone

SGSNMFS

OMC-CS






1 � 1 � 15


Observation Tools [cont.]

� Interfaces Traces: Capture messages through each interface

MSC/VLRGGSN

BTS BSC

BTS

BTSBSC

Circuit Core

Network

IPNetwork

GPRSbackbone

SGSNMFS

Drive-testsAbis trace

A trace

Post-Processing tool






1 � 1 � 16


Interface Trace

Use trace MS to capture

signaling and signal

characteristics

Capture/decode signaling

between BSC and BTS with

"protocol analyzer"

(Wandel, Tektronix,

Gnnettest, etc.)

Capture/decode signaling between MSC and BSC-TC (A or Ater MUX) with "protocol analyzer" (Wandel, Tektronix, Gnnettest, etc.)

Information source

�Give precise location (x,y) of problems

� Give downlink radio information

� Only way to localize a lack of coverage

� Only way to monitor competitor

�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

� GSM standard, can be used for arbitrage between manufacturers

� Complete information (message contents, time-stamp)

� Possible detection of User/MS/BSS/TC/NSS problems

Advantages

� High cost of equipment

� Very time-consuming

� Difficulty to perform a lot of calls

-> number of samples insufficient

-> only a few streets

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

�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 COCsmaximum!)

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

Drawbacks

Air interface

Abis Interface

A Interface

Interface

A interface :

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

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

IMSI Unknown in VLR Temporary Failure

IMSI Unknown in HLR Resource Unavailable

IMEI Not Accepted Switching Equipment Congestion

PLMN Not Allowed Normal Unspecified

Service Option Not Supported Recovery on Timer Expiry

Requested Service Not Supported Call Reject

Unassigned Number Interworking

Operator Determined Barring Protocol Error

User Alerting Network Failure

Facility Not Subscribed Congestion

No Route to Destination

Normal Call Clearing

User Busy

Invalid Number Format

Call Reject

Interworking

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

Abis interface : The main advantage of the Abis trace is to allow a detailed and precise assessment of the radio quality of a cell at TRX

level. Both DL and UL paths can be observed and compared.

Air Interface : The main advantage of the Air trace is to assiciate a radio quality measurements to a given geographical area of the

network.

From B7 release, the RMS feature implemented in the BSS provides a good level of information allowing to reduce the number of Abis

traces and drive test to be done for radio network optimization.






1 � 1 � 17


Example of Abis & A Traces

K12 / K15 Protocol Analyzer






1 � 1 � 18


Example of Traces Post-Processing

�

Detailedvisibility on calls& data

sessions

� Enter subscriber’s ID - Select time frame

FailingCalls

highlighted

Visibility / Services

< 3 seconds to display individual activity

�

Link to multi-interface& protocol decoding for deep investigation

Customer complaint analysis






1 � 1 � 19


Example of Traces Post-Processing [cont.]

View at BSC level

Detailed call analysis shows that a group of subscribers owning the same handset keep trying a LU every 2s

Abnormal level of Location updates:

2 of biggest cities particularly impacted

Ven

dor

3 H

ands

et 1

Ven

dor

1 H

ands

et 3

Ven

dor

5 H

ands

et 2

Ven

dor

2 H

ands

et 2

Ven

dor

4 H

ands

et 1

V

endo

r 5

Han

dset

1V

endo

r 2

Han

dset

1V

endo

r 4

Han

dset

2V

endo

r 1

Han

dset

4V

endo

r 1

Han

dset

2V

endo

r 2

Han

dset

4V

endo

r 3

Han

dset

2V

endo

r 4

Han

dset

4V

endo

r 4

Han

dset

3V

endo

r 2

Han

dset

3V

endo

r 2

Han

dset

5V

endo

r 3

Han

dset

3V

endo

r 3

Han

dset

4

+

-

Location Update Failures per IMSI

Best / Worst performing handsets

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






1 � 1 � 20


Example of Drive-Test






1 � 1 � 21


Performance Measurement Counters

� Count "events" seen by sub-system, value reported periodically

+ Low cost: collected directly at OMC

+ Compact data: possibility to store counters for a complete network

- Raw information, having to be consolidated to be understandable

- Manufacturer's dependent: questionable/difficult to compare

- Weak to analyze other sub-systems

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






1 � 1 � 22


Exercise

� Draw the BSS PM counters flow on the chart

� In which sub-system are the BSS QoS indicators computed and stored?

BSC

BSC

BSC

OMC-R

OMC-R

OMC-R

NPO






1 � 1 � 23


Alcatel-Lucent BSS Counters

� Performance Management implementation

� Easy and cost-effective way to monitor network and carried traffic

� Principle:

� For a given duration (granularity period) typically 1 hour or ½ hour

� To count pre-defined events occurring on the Abis or A interface, or internal events.

� Counters stored with breakdown per network component (i.e. cell)

� About 1100 counters are available (only for GSM).

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

Alcatel-Lucent has chosen to implement PM counters in the BSC and to increment them mostly on Abis

interface signaling messages.

Other suppliers may have chosen to increment them on A interface signaling messages or to implement

them in the BTS.

Therefore caution should be taken when interpreting QoS indicators value since some discrepancies may be

observed due to these possible choices.

In order to provide the operators with an easy and cost-effective way to monitor their network and carried

traffic, BSS manufacturers have implemented specific software features, called performance management.

The principle is to count for a given duration called granularity period (typically 1 hour) pre-defined events

occurring on the Abis or A interface, or internally. These counters are stored for each duration, with

breakdown per network component (i.e. cell).






1 � 1 � 24


BSS Counter Example

Counter Reference Counter Name

Smallest element for which the counter is provided

All counters are described in PM Counters document.






1 � 1 � 25


BSS Counter Example [cont.]

O 20 40 60 80 … … t

5 ts

10 ts

15 ts At the end of the hour:180 samples every 20sHourly value = SUM of sample /180

ts available

All counters are described in PM Counters document.






1 � 1 � 26


Exercise

� Observation Means: find the best source of information.

9 – In a building, one is thinking that an elevator is inducing EM trouble, how to confirm?

8 – discriminate problems between BSS/NSS. BSS and NSS from different providers.

7 – compare networks quality

6 – history of network quality for several weeks

5 – localize abnormal cell in a network

4 – localize precise location of a radio pb

3 – get average network quality

Counters

Best source

Type 31 : RMS

Why

10 – Identify potential interfering cells of 1 cell

2 – monitor user failures

1 – overall radio quality of 1 cell

Observation to be done

EM: Electro-Magnetic






1 � 1 � 27

4 Introduction to K1205 PC Emulation






1 � 1 � 28


Usage

� The trace done with K1205 can be read:

� Directly on K1205 itself

� On any PC Windows NT® with dedicated emulation software

� Practical exercises will be done during the course using this software

� The following slides and exercises are here to teach you the basic skill needed to operate the tool for A Interface decoding






1 � 1 � 29


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.






1 � 1 � 30


Filter Configuration

� Configure your filter to remove some messages and protocols => Bypass Protocol Filterand select:

� SCCP Except UDT

� Keep 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






1 � 1 � 31


Monitor Screen

Short View

1 line / message

Short View

1 line / message

Frame View

Full decoding of

selected message

Frame View

Full decoding of

selected message

Packet view

Message content

in hexadecimal

Packet view

Message content

in hexadecimal

To extract 1 callTo extract 1 call






1 � 1 � 32


Extract a Call

� How to find a specific message?

� Edit - Find (or ctrl + F3)

� Select All Logical Links.

� Choose the protocol.

� Select the message studied.

� Use F3 to find another same message.

� How to extract a call from these traces?

� Click on the Zoom button.

� Select CC message (Connection Confirm).

� And UnZoom + Zoom to get:

� SLR: Source Location Reference

� LR: Destination Location Reference

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.






1 � 1 � 33


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.






1 � 1 � 34


Exercise

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

1) Zoom on a CC message:

Find the definition of all messages in the Frame View.

2) Zoom on a CR message with LUREQ.

How to extract the complete call?

3) Use “Find” to extract a call with an ALERTING message. Can you see the CC message? If not, Why?






1 � 1 � 35

5 Indicators Definition






1 � 1 � 36


BSS Indicators Definition (Alcatel-Lucent)

� Formula of counters

� Call_drop_BSS = Σ (Drops BSS Int. Fail. + Drops BSS Remote TC)

= Σ (MC14c + MC739)

� RTCH_Erlang_Total = Σ (Occupancy RTCH) / 3600

= Σ (MC380a + MC380b) / 3600

� Difference: Key Performance Indicator (KPI) or Detailed Indicator

� KPI: For high-level monitoring, to measure progress towards organizational goals. KPI's are a subset of indicators, selected by radio engineers & managers.

"If all KPIs are fine, then everything is fine"

� Detailed: Any other indicator, within the 4000 ALU Indicators! For troubleshooting and analysis of problems, known only by expert radio engineers.






1 � 1 � 37

� Call drop %

Rate of calls dropped after successful assignment

� E2E Call Set-Up Success %

Rate of call setups successfully

� Outgoing Handover Success %

Rate of successful outgoing external and internal intercell SDCCH and TCH handovers

� TCH congestion %

Rate of RTCH not allocated during normal assignment due to congestion on Air interface.

� SDCCH unsuccess %

Rate of SDCCH not allocated during radio link establishment due to congestion, radio problems or other problems.


Typical KPI for BSS

B11






1 � 1 � 38


Typical KPI for Drive-tests

� Call Establishment Success Rate

� Rate of DL RxQual samples < 3

� Rate of DL RxLev samples > -80dBm (beware of power control…)

� Voice Quality (MOS)

MOS : Mean Opinion Score






1 � 1 � 39


Typical Thresholds

� Not taking into account coverage or frequency planning

96.0%% Out HO Efficiency

1.0%% SDCCH Assign Cong

0.5%% SDCCH Drop

1.5%% RTCH Assign Fail

2.0%% RTCH Assign Cong

97.0%% Call Setup Success (ALU formula)

1.20%% RTCH drop

1.50%% Call Drop

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.






1 � 1 � 40


Typical KPI Report

� Observe this report from NPO. Is this cell below typical CSSR threshold?

Call success - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) - 01/07/2009 To 07/07/2009

(Working Zone: Training - Medium)

0

100

200

300

400

500

600

700

800

900

01/07/2009 02/07/2009 03/07/2009 04/07/2009 05/07/2009 06/07/2009 07/07/2009

nb

97.5%

98.%

98.5%

99.%

99.5%

100.%

%

Assign Unsucc

Call drop

SDCCH drop

% End to End Call setup

% Call success

% Call setup

Call setup is above 97%






1 � 1 � 41

6 Methodological Precautions






1 � 1 � 42


Objective

� Avoid typical errors regarding indicators interpretation

� Rule: Good indicator value all componants are good

� Ex: a BSC with CDR = 1% … not all cells in the BSC are good !

a Cell with CSSR = 99% for one day … not all hours are good !






1 � 1 � 43


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 rate

cell 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%






1 � 1 � 44


Global Indicator Validity

� To be reliable, an indicator must be based on a sufficient number of events. Estimation theory gives a fresh look on our KPI:

� If a sample (number of calls) is too small, then the indicator doesn't represent a statistical reality but just a random occurrence of events.

MinMaxNb Calls

1.7%2.3%10000

1.6%2.4%5000

1.5%2.5%3000

1.4%2.6%2000

1.1%2.9%1000

0.9%3.1%600

0.6%3.4%400

0.1%3.9%200

0.0%4.7%100

0.0%10.7%10

If displayed CDR = 2%, but nb of calls = …

� if « p » is the probability of success for a complete population

� if one is measuring the probability P based on a sample of size « N »

� There is a probability of 95 % that p is between: P +/- 1.96*[(p*(1-p))/n]½

� Example: for p = 90 % and N = 100 => [ 84,12% ; 95,88% ]

On Alcatel-Lucent QoS monitoring tool (MPM application on OMC-R, NPA or RNO), NEs (BSS, Cell or TRX) are

highlighted with bad QoS indicator value if enough corresponding events have been observed (called Validity

threshold).

Examples:

� Cells with bad Call Drop rate will be highlighted if CDR > CDR_threshold and if the Number of Calls is greater

than the CDR Validity threshold.

� Cells with bad Outgoing handover success rate will be highlighted if OHOSUR > OHOSUR_threshold and if the

Number of Outgoing Handovers is greater than the OHO Validity threshold.






1 � 1 � 45


Time Period Aggregation

� TCH congestion rate at busy hour:

� Weighted average of cell congestion at the busy hour of the network?

� Weighted average of cell congestion rate for its specific busy hour?

time

erlangcongestion %

Cell A

Cell B

Cell C

Max traffic = Busy HourCongestion @ Busy Hour

Max congestion

Busy Hour at BSC levelnot the same as cells BH

BHa

BHb

BHc

BSCΣmax bh

Usually:

� Cell Busy Hour = hour of the day where max TCH traffic (in erlang) is observed.

� BSC Busy Hour = hour of the day where max TCH traffic (as the sum of the TCH traffic of all cells of the BSS)

is observed.






1 � 1 � 46


Exercise

�Is the conclusion given for each indicator right?

15346

4000

2000

215

4500

3267872

2315

2456435

Samples (calls)

BSS1 belonging to MSC Stadium

has a call setup success of 95%

LA = BSS1+BSS2 has a call drop

of 2.3%

Cell 15, 13 has certainly a

trouble

The call drop for BSS_1 is good

In France, call setup success=

97%

There is a good call setup

success rate for cell 15, 145

All the cells have a good call

drop

Conclusion

For BSS 1, call drop of 2%

For BSS 2, call drop of 3%

MSC <<Stadium>> has a call setup success of 95%

Call drop for cell 156,13 = 5%

Call drop rate for BSS <<BSS_1>> = 1%

In Paris: 2500 cells with 95% of call setup success

In the rest of France: 5000 cells with 98%

Call setup success for cell 15, 145 = 99,5%

NOKCall drop = 0,9% in your country

OK / NOK ?Indicator

dsama

Texte surligné






1 � 1 � 47

Self-assessment on the Objectives

� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module

� The form can be found in the first partof this course documentation






1 � 1 � 48

End of ModuleIntroduction






Module 2Global Indicators3JK11044AAAAWBZZA Issue 01








EVOLIUM Base Station Subsystem � BSS B10 Introduction to Quality of Service and Traffic Load MonitoringGSM QoS Monitoring � Global Indicators

1 � 2 � 2

Blank Page


First edition B11 MR1Xavier Pourtauborde29-June-201001


Document History






1 � 2 � 3

Module Objectives


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






1 � 2 � 4








1 � 2 � 5

Table of Contents


1 Indicators Reference Name 7Description 8

2 Indicators Classification 9BSS Counter Collection Mechanism 10BSS Performance Measurement Types 11Classification of GSM Indicators 12Formalism of Telecom Procedures 13SDCCH Traffic 14TCH Traffic 15QoS SDCCH 16QoS RTCH 17QoS Call Statistics 18Handover Causes 19Outgoing Handovers 20Incoming Handovers 21Intracell Handovers 22Handover Statistics per Couple of Cells 23Self-assessment on the Objectives 24End of Module 25






1 � 2 � 6









1 � 2 � 7

1 Indicators Reference Name






1 � 2 � 8

1 Indicators Reference Name

Description

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

UnitFamily

Procedure Type Joker

Prefix Sub-type

mandatory

optionalTechnology

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






1 � 2 � 9

2 Indicators Classification






1 � 2 � 10


BSS Counter Collection Mechanism

� Cumulative

� The counter is incremented at the occurrence of a specific event.

� Abis or A message, or internal event.

� At the end of a collection period, the result is the sum of the events.

� Inspection

� Every 20 or 10 seconds, a task quantifies an internal resource status (usually a table).

� At the end of a collection period, the result is the mean value.

� Observation

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

� Radio Measurement Statistics

� Aggregation of all "Measurement Results" for a day and a TRX/Cell.






1 � 2 � 11


BSS Performance Measurement Types

2G Traffic flow meas.180Overview meas.110

B11IP transport35B9Voice Group Call Services34B9Electro-Magnetic Emission 33B8Change of frequency band meas.32

Radio Measurement Statistics31SMS CB meas.30Directed retry meas.29SDCCH HO28

1 cell2G TCH incoming HO per adj. meas.2740 cellsTCH outgoing HO per adj. meas.26

SCCP meas.25SMS PP meas.19A interface meas.18

15 cellsTCH observation1515 cellsOutgoing external HO obs.1415 cellsIncoming external HO obs.1315 cellsInternal HO obs.121 cellTCH meas. obs.11

15 cellsSDCCH obs.10N7 meas.9X25 meas.8LapD meas.7

40 cellsTCH HO meas.640 cellsResource usage on TCH meas.540 cellsResource usage on SDCCH meas.440 cellsResource usage on CCCH meas.340 cellsResource availability meas.240 cellsTraffic meas.1

Since …LimitationsNameType

B11

A standard PM type can be activated for the whole network. It means that the related counters are

reported for all the Network Elements they are implemented on (TRX, CELL, N7 link, X25 link, LAPD link,

Adjacency).

A detailed PM type can be activated only on a sub-set of the network. It means that the related counters

are reported only for a limited number of Network Elements:

� 40 cells per BSS for PM types 1, 2, 3, 4, 5, 6, 26, 29

� 15 cells per BSS for PM types 10, 12, 13, 14, 15

� 1 cell per BSS for PM types 11, 27

Counter numbering rules:

� Cyz: cumulative or inspection counters in PM types 1, 2, 3, 4, 5, 6, 18, 19, 25, 26, 27, 28, 29, 30, 32, 180

� Ly.z: cumulative counters in PM type 7 (L stands for LAPD link)

� Xy.z: cumulative counters in PM type 8 (X stands for X25 link)

� Ny.z: cumulative counters in PM type 9 (N stands for N7 link)

� Syz: observation counters in PM type 10 (S stands for SDCCH)

� Ryz:: observation counters in PM type 11 (R stands for Radio measurements)

� HOyz: observation counters in PM type 12, 13, 14 (HO stands for HandOver)

� Tyz: observation counters in PM type 15 (T stands for TCH)

� RMSyz: cumulative counters in PM type 31 (RMS stands for Radio Measurement Statistics)

� MCyz or MNy.z: cumulative counters in PM type 110 (M stands for Major)






1 � 2 � 12


Classification of GSM Indicators

Control Channels

Traffic load

Call statistics

Global QoS Handover Resource availability

Multiband

Densification techniques

GSM indicators

3G to 2G HOA Channel availability

SCCP

TCH

RTCH

Couple of cell

SDCCH/TCH HO

Intracell HO

Multilayer / MultibandNetwork

Concentric cells

Inter-PLMN HO

SDCCH availability

RTCH availability

SDCCH

Outgoing HO Directed retryDynamic SDCCHSDCCH

Incoming HO

HO causes






1 � 2 � 13


Formalism of Telecom Procedures

“Telecom procedure”-ATTEMPT

“Telecom procedure”-SUCCESS

“Telecom procedure”-whose channel is ALLOCATED in BSC

channel activationfailure

assignment/HOexecution failure

PREPARATION phase

EXECUTION phase

failure in channel established phase

the MS has seized the channel

- radio link failure- handover execution failure(with or without reversionto the old channel)- BSS problem- NSS problem

- radio link failure- BSS problem- NSS problem

“Telecom procedure”-REQUEST

- BSS problem- NSS problem

- congestion

no resource availablein BSC

resource availablein the BSC

channel activationsuccess

(start)

(end)

Success Rate = (Success) / (Request)Efficiency Rate = (Success) / (Allocated)Unsuccessful Rate = (Preparation & Execution Failures) / (Request)Failure Rate = (Execution Failures) / (Request)






1 � 2 � 14


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.






1 � 2 � 15


TCH Traffic

� Traffic Load and Traffic Model

� TCH traffic RTCH Traffic

Resource

Occupancy

TCHErlang

Full Rate

Erlang

Full RateAllocated

Full RateMean TCH

Time

Half Rate

Erlang

Half RateAllocated

Half RateMean TCH

Time

Blocking Peak

Ratio ofHR Traffic

TCHMultiband

Occupancy

Traffic Model

REQUESTSAssign / HO / DR

SUCCESSAssign/ HO/ DR

HO PER CALL

REQUESTS

FR, DR, DR/EFR, AMR, DATA

Speech Version&

Channel Type

ALLOCATIONS

FR, 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).






1 � 2 � 16


QoS SDCCH

� GLOBAL Quality of Service

� SDCCHSDCCH

Established

Phase

Drop Rate

Drop Radio Drop HO

Unsuccess

Congestion

Assignment Phase

/

Handover

RadioFailure

BSS Failure

Access Reject

Dynamic Allocation

Drop BSS






1 � 2 � 17


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

Queued

Success

Queue Full

HigherPriority

Timeout

AssignQueued

NormalAssign.






1 � 2 � 18


QoS Call Statistics

� GLOBAL Quality of service

� Call statisticsCall 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

End to End Call Setup

Success Rate






1 � 2 � 19


Handover Causes

� Handover STATISTICS

� Handover causes

Handover causes

HO causes

All

HO

cause

distribution

Outgoing HO Incoming HO

HO standard

cause

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






1 � 2 � 20


Outgoing Handovers


� Outgoing 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






1 � 2 � 21


Incoming Handovers


� Incoming 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






1 � 2 � 22


Intracell Handovers


� Intracell handovers

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

� NB_TCH_HO_ATPT_30_ReturnCSZone=MC481 (Type 110)

CDR Radio CDR BSS


Failure BSS

Call Drop Rate

Congestion

Efficiency

Intracell HO






1 � 2 � 23


Handover Statistics per Couple of Cells


� Handover statistics per couple of cell

HO Success Distribution

Success Rate

Efficiency


HO statistics

per Couple of Cell






1 � 2 � 24









1 � 2 � 25

End of ModuleGlobal Indicators






Module 3Detailed Indicators









EVOLIUM Base Station Subsystem � BSS B10 Introduction to Quality of Service and Traffic Load MonitoringGSM QoS Monitoring � Detailed Indicators

1 � 3 � 2

Blank Page


First edition B11 MR1Xavier Pourtauborde28-june-1001


Document History






1 � 3 � 3

Module Objectives


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






1 � 3 � 4








1 � 3 � 5

Table of Contents

Switch to notes view! Page

1 Call Setup Principles 7Objective 8Call Setup Procedure 1/2 9Call Setup Procedure 2/2 10Call Setup phasing 11Paging 12Successful Paging Procedure 13Paging Discarded due to PCH Congestion 14Paging Coordination 15Paging Request, Air Interface 17

2 Typical Call Setup Failures 18RLE – Originated Call Success 19RLE – Terminated Call Success 20RLE - Channel Request Message 21RLE – Call Distribution 22RLE - SDCCH Congestion Failure 23RLE - SDCCH Congestion 24RLE - SDCCH Congestion 25RLE - SDCCH Cong. Impacts 26RLE - SDCCH Cong. Causes & Solutions 27RLE – Dynamic SDCCH 29RLE - SDCCH Radio Failure 30RLE - Real SDCCH Radio Failures 31RLE - Ghost RACH 32RLE - Ghost RACH Causes 33RLE – Same BCCH-BSIC couple (Channel Req.) 35RLE – Same freq-BSIC couple (HO Access) 36RLE - BSS Failure 38RLE - Summary 39RLE - Indicators 40Convention 41SDCCH Phase – Originated Call Success 42SDCCH Phase – Terminated Call Success 43SDCCH Phase – Location Update Success 44SDCCH Phase - Drops 45SDCCH Phase - Radio Drop 46SDCCH Phase - BSS Drop 47SDCCH Phase - HO drop 48SDCCH Phase - Counters 49SDCCH Phase - Indicators 50SDCCH Phase - Exercise 51TCH Assignment – Success Case 52TCH Assignment – Phase Split 53TCH Assignment – MS Capabilities 54TCH Assignment - Congestion 55TCH Assignment – Exercise 56TCH Assignment - Radio Failure in TCH Uplink 57TCH Assignment - Radio Failure in TCH Downlink 58TCH Assignment - Radio Failure at T3107 expiry 59TCH Assignment - BSS Problem 60TCH Assignment - Counters 61TCH Assignment - Indicators 62TCH Assignment - Exercise 63

3 Key Performance Indicators 64Reminder 65






1 � 3 � 6



SDCCH Congestion Rate 66SDCCH Failure Rate 68SDCCH Drop Rate 70TCH Assign Unsuccess Rate 72TCH Assign Unsuccess Rate – Preparation Phase 73TCH Assign Unsuccess Rate – Execution Phase 74Cell Congestion Rate 75Call Setup Success Rate 76Call Success Rate 78End to End Call Setup Success Rate 79Alc_Mono_Call 81Differences between CSSR and E2ECSSR 82Self-assessment on the Objectives 83End of Module 84






1 � 3 � 7

1 Call Setup Principles






1 � 3 � 8


Objective

� Description of the main call setup success and failures cases, with:

� Main specific counters

� Main protocol timers

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






1 � 3 � 9

Subscription Checking(calling party rights, call barring)

Translation of the Called Number


Call Setup Procedure 1/2

MSC/VLR

Establish Indication "CM Service Request"

HLR/AuC/SCP/

Channel Request (RACH)

Immediate Assignment (AGCH)

Security Checks

MM Authentication Procedure

CC Setup

CC Call Proceeding

Assignment Request (CIC)

Assignment Complete

Assignment Command

Assignment Complete

MM/RR Ciphering Procedure

MM/RR TMSI Reallocation Procedure

Call

Setup

Phase

MM Identity Request

Release of SDCCH Radio

Channel

SDCCH

TCH

CCCH

BSSMS

Connect Req. (CR)Connect Conf. (CC)






1 � 3 � 10


Call Setup Procedure 2/2

MSC/VLR HLR/AuC/SCP/

BSSMS

ISUP ACM

CC Alerting

ISUP IAM

Conversation phase

CC Connect

CC Connect Ack.

Called partyfree & ringing

ISUP ANC Called partyAnswered

MAP Send Routing Info.

MAP Send Routing Info. ResIf Called Nb= MSISDN

CC Disconnect

CC Release

CC Release Complete

ISUP CLF

ISUP RLGRelease of Radio Resources

Call

Setup

Phase

CallRel.Phase

Conv.Phase

V-MSC/VLRTCH

Steps of a Basic SS7 Call:

1) The caller takes the phone "off-hook", dial the destination number. The subscriber signaling pass this

information to the local calling office.

2) The local originating office which use SS7, encapsulates the dialed number and the CPC (calling Party

Category) information in to the first signal IAM (Initial Address Message) to setup the call to the destination office. In some cases IAM can be replaced with IAI (Initial Address Message with Additional

Information) to pass more information.

3) On the route to the destination each receiving office checks the DPC (Destination Point Code) with its

own Point Code to see if the message is destined to itself. If not it transfers the message to the next

office in the route. When the destination office finally receives the IAM or IAI, it checks the subscriber

number to see if it's free. If free then sends back the ACM (Address Complete Message).

4) At this point, the voice circuit is opened, ring back tone is put on the circuit back to the caller and

ringing current is sent to the dialled number's phone.

5) When the called subscriber answers, the destination switching office sends back ANC (Address Charge Message) to the first office to begin call charging.

6) When the conversation is over, to release the call circuit, the originating switching office sends CLF (Clear Forward) and the destination switching office sends back the RLG (Release Guard) signals.






1 � 3 � 11


Call Setup phasing

� 4 steps for a call establishment

� Each phase has a specific utility and some weaknesses

� In the table, indicate which phases are used for each type of connection:

Radio Link EstablishmentSDCCH PhaseTCH assignmentAlerting/CNX Phase

��Alerting/Connection4

��TCH Assignment3

��SDCCH Phase2

��Radio Link Establisment1

GPRS TransferCallSMSSignallingCALL SETUP PHASES

Alerting/Connection4

TCH Assignment3

SDCCH Phase2

Radio Link Establisment1

GPRS TransferCall (OC/TC)SMSSignalling (LU,

IMSI Det)CALL SETUP PHASES

dsama

Crayon

dsama

Crayon

dsama

Crayon

dsama

Crayon

dsama

Crayon

dsama

Crayon

dsama

Crayon






1 � 3 � 12


Paging

� MS is "IMSI-attached" to the network: the MSC/VLR knows the L.A. in which the MS is located.

MSC

BSC 1

BSC 2

ISUPIAM

CSPAG

LAC 002

LAC 001

LAC 002

PAGINGCOMMAND

to each cell in the LAC 002

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

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






1 � 3 � 13


Successful Paging Procedure

CS Paging (MS1)

Multiple Paging Command

(MS1 pgr1, MS2 pgr1, MS3 pgr2)

CS Paging (MS2)

CS Paging (MS3)

Paging Request for Group 1

(MS1 , MS2)

MS3

Paging Request for Group 3

(MS3)

Establishment Indication

incl. Paging Response

Connection Setup

T3113

timer stopped

MC01

MC8a

MC925b

MC925b

MC925g x 3

MC930 x 1

MC940

MC940

MC940

Since B10, BSC can send Multiple Paging Command

MSC sends a PAGING message and starts the timer T3113 to supervise the PAGING RESPONSE message

from the MS. T3113 is started for each Paging !

The MSC may repeat the PAGING message if no answer arrives before T3113 expiry.

The BSC starts T_SEND_MULTIPLE_PAGING_CMD timer (assumed to be not yet running) when the first

PAGING message (MS1) is received.

When the number of PAGING messages queued in the BSC equals

NB_MAX_MSG_MULTIPLE_PAGING_CMD, or at T_SEND_MULTIPLE_PAGING_CMD expiry:

� Multiple Paging Command is built and send to the cells.

dsama

Crayon

dsama

Crayon






1 � 3 � 14


Paging Discarded due to PCH Congestion

CS Paging (MS1)

Multiple Paging Command

(MS1 pgr1, MS2 pgr1, MS3 pgr2)

CS Paging (MS2)

CS Paging (MS3)

MS3

T3113

timer expires

MC8a

MC940

MC940

MC940

MC925h x 1

Paging Queue is fullPaging Command is

rejected

CS Paging (MS3)

MSC

MSC timer

In case of RSL DL Congestion (= LAPD Congestion), the Pagings are not sent on the Abis interface

anymore.

IF MSC timer T3113 expires, the MSC will retransmit the paging over the whole LAC or even more (whole

BSC, whole network, …)






1 � 3 � 15


Paging Request, Air Interface

� Depending on how the MS is identified by the MSC, the Paging Request is built by the BTS using a certain type:

4x TMSI3 x TMSIor 2 x TMSI + 1 IMSI

IMSIor TMSIor 2 x TMSIor 2 x IMSIor 1 TMSI + 1 IMSI

Possible combinations

432Max. paged MS

Type 3Type 2Type 1

Paging Request

most common

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

Paging.






1 � 3 � 16

2 Typical Call Setup Failures






1 � 3 � 17


RLE – Originated Call Success

Radio Link EstablishmentSDCCH Phase

TCH assignment

Alerting/CNX Phase

MC8cMC925d

MC148

IP21 only in case of IP BSS

MC8b

MC925a

MC925e

MC02

C253

C256

CR and CC messages are contains the SCCP references to be used for the call

The SDCCH resource allocation is performed by the BSC. Once allocated, the SDCCH channel is activated by

the BTS on BSC request.

T3101 is the guard timer for the SDCCH access from the MS. The Default value is 3 seconds.

The SCCP Connection Request message is conveyed on an A interface PCM timeslot chosen by the BSC

(called COC).

The SCCP Connection Confirm message is conveyed on a COC chosen by the MSC which can be located on a

different PCM than the one of the COC used by the BSC to send signaling messages to the MSC.

Originating + Destination Point Codes : N7 physical address

Originating + Destination References : SCCP reference between MSC and BSC

Multiple SACCH Modify (New in B10) : request to send ASAP some system information messages that should

be updated when the MS moves from Idle Mode to Dedicated Mode (usually, the SI5, with the list of

neighbours).

C253 and C256 are type 25 counters (related to SCCP measurements).

dsama

Texte surligné






1 � 3 � 18


RLE – Terminated Call Success

Radio Link EstablishmentSDCCH Phase

TCH assignment

Alerting/CNX Phase

MC8cMC925d

MC148

IP21 only in case of IP BSS

MC8b

MC925a

MC925e

MC01

C253

C256

MC8a

A paging message is broadcast by the MSC to all BSCs controlling cells belonging to the same Location Area

as the one of the paged MS.

In case no MS is accessing the SDCCH channel (T3101 expiry) then the BSC does not repeat the Immediate

Assignment since the MS may have accessed an SDCCH in another BSS. It is up to the MSC to repeat Paging if

T3113 expires (usually around 7 seconds).

MC8A counts the number of Paging Command messages sent on a cell.

MC01 counts the number of MSs which have successfully accessed an SDCCH in a cell as part of a Mobile

Terminating (MT) call.

CR: Complete L3 Info

dsama

Texte surligné

dsama

Texte surligné

dsama

Texte surligné

dsama

Texte surligné

dsama

Texte surligné

dsama

Texte surligné






1 � 3 � 19


RLE - Channel Request Message

� Format of the message: 1 byte (8 bits)

Random ReferenceEstablishment Cause




12345678

� Valid causes :� 000 : Location update (Normal, periodic, IMSI attach)

� 100 : Terminating Call

� 101 : Emergency Call

� 110 : Call Re-establishment

� 111 : Originating call (Not Emergency)

� 011 : If GPRS is implemented in the cell

� Invalid causes : 001, 010, 011

NECI: New Establishment Cause Indication (0: not supported, 1: supported), is always set to 1 in Alcatel-

Lucent BSS






1 � 3 � 20

� Mobile Originating Cause Split: MC02

� = MC02a+MC02b+MC02c+MC02d+MC02e+MC02f+MC02g+MC02h+MC02i


RLE – Call Distribution

MC02A: Location Update & IMSI Attach

MC02B: SMS

MC02C: Supplementay Services

MC02D: Location Update with follow-on TCH assignment for call establishment

MC02E: Call Reestablishment

MC02F: L3 Info unknown by BSC but forwarded to MSC

MC02G: IMSI Detach

MC02H: Normal or Emergency call

MC02i: Location Services (LCS)

C190 (Type 19) SMS Originated SDCCH

C191 (Type 19) SMS Terminated SDCCH

Could you find any other counters that would give more details about SMS?

In NPO, in indicator family "SMS"

Call Re-establishment (3GPP 24.008, 4.5.1.6)

The re-establishment takes place when a lower layer failure occurs and at least one MM connection is active

(i.e.. the mobile station's MM sublayer is either in state 6 "MM CONNECTION ACTIVE" or state 20 "WAIT FOR

ADDITIONAL OUTGOING MM CONNECTION").

Supplementary services (SS) in GSM are a means of enriching the user experience. An SS may, for example,

forward a call in the case of no reply from the called party, bar certain outgoing or incoming calls, show the

number of the calling party to the called party, etc. The subscription to supplementary services is contained

in the HLR and is sent to the MSC/VLR during registration.

Name identification Calling name presentation (CNAP)

Call forwarding Call forwarding – unconditional (CFU)

Call forwarding – busy (CFB)

Call forwarding – no reply (CFNRY)

Call forwarding – not reachable (CFNRC)

etc.






1 � 3 � 21


RLE - SDCCH Congestion Failure

� Main failure cases for Radio Link Establishment

SDCCH Assignment Unsuccess Rate

SDCCH Assignment Failure Radio Rate

SDCCH Assignment Failure BSS Rate

SDCCH Assignment Failure Congestion Rate

LapD Problem

LAPD_unavailable_time (L1.16, type 7)

LAPD_Time_LAPD_Cong (L1.18, type 7)

This problem could impact any other phase as well

LAPD Congestion will lead to

1/ Defense mechanism :

if UL RSL Congestion: Channel Requests, SMS and Detection of Call drop due to Remote Transcoder are

discarded

if DL RSL Congestion: Paging, "SDCCH" Channel activation and SMS are discarded

2/ If congestion continues and the Lapd buffers overflow, then the LapD link is RESET.

Congestion and Reset are counted in the LapD counters.






1 � 3 � 22


RLE - SDCCH Congestion

� BSC reaction depends on EN_IMM_ASS_REJ value

� IF EN_IMM_ASS_REJ = DISABLE, no message is sent to MS

� MS wait T3120 expiry and sends automatically another Channel Request

� Up to MAX_RETRANS times (def = 2)

T3120(≈130ms)

T3120

1

2

0

MC8c

MC8c

MC8c

T3126

MS goes back to IDLE MODE & displays "Network Error"

MC04

MC04

MC04

Time during which the SDCCH are all busy in the cell:SDCCH_time_system_congestion = MC803MC803

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

* 250 and 250+T-1 for a phase 1 MS where:

T=Tx_integer parameter (1 value per cell chosen between 3 to 50 slots)

* S and S+T-1 for a phase 2 MS where:

T=Tx_integer parameter (1 value per cell chosen between 3 to 50 slots, with 1 slot = 0.577ms)

S is a parameter depending on the CCCH configuration and on the value of Tx_integer as defined in the

following table 3GPP 331121 from 44.018:

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

3, 8, 14, 50 55 41

4, 9, 16 76 52

5, 10, 20 109 58

6, 11, 25 163 86

7, 12, 32 217 115

By default Tx_integer=32, then S=217. Therefore T3120 is between 125ms and 144ms.

T3126 is MS dependent, greater than T3120 but less than 5s.

After T3126 expiry, MS display "Network Error", except in case of LU, in which case the MS attempts to

reselect another cell and repeat the procedure.






1 � 3 � 23


RLE - SDCCH Congestion

� BSC reaction depends on EN_IMM_ASS_REJ value

� IF EN_IMM_ASS_REJ = ENABLE, "Imm. Assg. Reject" is sent to MS

� MS is forced to wait WI_xx before sending another Channel Request

� Up to MAX_RETRANS times (def = 2)

WI_OC(=5s)

WI_OC

1

2

0

MC8c

MC8c

MC8c

T3126

MS goes back to IDLE MODE & displays "Network Error"

MC04

MC04

MC04

Time during which the SDCCH are all busy in the cell:SDCCH_time_system_congestion = MC803MC803

IMMEDIATE ASSIGMENT REJECT(WI_OC)(AGCH)



MC8d

MC8d

MC8d

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

WI_DTM: Value of Wait Indication for DTM requests

WI_EC: Value of Wait Indication for Establishment cause = “Emergency call”.

WI_OC: Value of Wait Indication for Establishment cause = “Originating call”.

WI_OP: Value of Wait Indication for Establishment cause = “Location updating” or “Other procedures which

can be completed with an SDCCH”.

Wait indication used in IMMEDIATE ASSIGNMENT REJECT or PACKET ACCESS REJECT, when not in PMU CPU

overload situation.

Wait indication used in IMMEDIATE ASSIGNMENT REJECT or PACKET ACCESS REJECT, when in PMU CPU

overload situation.






1 � 3 � 24


RLE - SDCCH Cong. Impacts

� In case of congestion, with default parameters:

� For each "subscriber" call attempt, how many times the counter MC04 is incremented ?

� After MS finished its "n" automatic attempts, what is the next step ?

1 2 30

Displays "Network Error"

Automatic reselection + New call attempt

Subscriber should dial again

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

dsama

Texte surligné

dsama

Crayon

dsama

Crayon

dsama

Crayon






1 � 3 � 25


RLE - SDCCH Cong. Causes & Solutions

� Location area border results in excessive location update and SDCCH attempt

� Inadequate LA design (too many LA's, or cell defined with wrong LAC value)

� Modify CRH (Cell Reselect Hysteresis)

� Increase T3212 (period location update)

� Road is crossing LAC border � Increase SDCCH capacity

� Insufficient system capacity, lack of SDCCH channels� Could be caused by TRX failure

� Add SDCCH channel

� Enable dynamic SDCCH Dynamic Allocation function

� Improper configuration of system parameters� TCH Queue (T11) is taking too long (while MS in queue, the SDCCH remains allocated)

� Increase RACH_TA_FILTER with care!

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

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

High SDCCH congestion can be observed at a particular period of the day due to a peak of LU requests

generated by a big group of subscribers entering a new LA at the same time (bus, train, plane).

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

High SDCCH congestion can be abnormally observed without real MS traffic in case a high level of noise or

the proximity of a non-GSM radio transmitter.

Solution = change the BCCH frequency or put an RX filter

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

barred.

Solution = Remove the barring






1 � 3 � 26

� Abnormal SDCCH traffic� Neighboring cell barred

� "Phantom" channel requests (explained in next slides)


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

Real Subscribers

The Ghosts !

Channe

l Reque

stEM

Noise






1 � 3 � 27


RLE – Dynamic SDCCH

� Some timeslots are configured as "SDD"

� BSC configures the SDD as TCH, unless all static SDCCH are busy.

� Particularly adapted to cells with peaks of LU or SMS.

CHANNEL ACTIVATION

If no SDCCH currently free,� verify if SDD can be reconfigured as SDCCH/8If Successful, then…

MC8c

MC148

MC802a Avg SDCCH subchannels busy on a SDD

MC802b Max SDCCH subchannels busy on a SDD

MC801a Avg TCH busy on a SDD

MC801b Max TCH busy on a SDD

…

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

SPECIFIC COUNTERS (Type 110 / Cell Level):

� MC800 Average number of available dynamic SDCCH/8 timeslots.

�MC801 & MC802 counters are ”Inspection Counters”; that means that the resource is checked regulary by the BSC and at the end

of the period, an average is done. Example: 3 physical channels are defined as Dyn SDCCH and the counter gives the following

indication:

�MC801a = 1.7 that means sometimes the 3 Dyn SD are allocated as TCH, sometimes only 2 of them, sometimes 1 or 0 and the

average is 1.7.

The FOLLOWING COUNTERS ARE IMPACTED BY the Dynamic SDCCH Allocation feature:

� MC28, MC29 The Number of busy radio timeslots in TCH usage takes into account the busy TCH timeslots and the dynamic

SDCCH/8 timeslots allocated as TCH.

� C30, MC31 The Number of busy SDCCH sub-channels takes into account the SDCCH sub-channels allocated on the static and

dynamic SDCCH/8 timeslots.

� C370a, MC370a, C370b, MC370b The Number of times the radio timeslots are allocated for TCH usage (FR / HR) takes into

account the busy TCH timeslots and the dynamic SDCCH/8 timeslots allocated as TCH.

� C/MC380a/b C/MC381a/b The Cumulated time (in second) the radio timeslots are allocated for TCH usage (FR or HR) does not

take care whether the TCHs are allocated on the TCH radio timeslot or on the dynamic SDCCH/8 timeslots.

� C39, MC390, C40, MC400 The Number of times or the Cumulated time (in second) the SDCCH sub-channels are busy does not

take care whether the SDCCH sub-channels are allocated on the static or dynamic SDCCH/x timeslot.

� C/MC34 C/MC380 The Cumulated time (in second) all TCHs / SDCCHs in the cell are busy does not take care whether the TCHs /

SDCCHs are allocated on the TCH radio timeslot /SDCCH/x timeslot or on the dynamic SDCCH/8 timeslots.

� C/MC320a/b/c/d/e Free TCH radio timeslots count the free TCH timeslots and the free dynamic SDCCH/8 timeslots.






1 � 3 � 28


RLE - SDCCH Radio Failure





MC8cMC925d

MC148

IP21

MC8b

MC149

T3101 expiry !! (def. 3s)

No Establishment Indication

Real problems

Ghost RACH

BSIC duplicates






1 � 3 � 29


RLE - Real SDCCH Radio Failures

� Unbalanced cell power budget� Uplink is OK (Channel Request received)

� Downlink is poor (BTS Tx is low, or MS Rx is poor)

� Bad coverage (ex.: moving car) or Interference (DL or UL)� Radio link is unstable

� Channel request could go through thanks to repetitions

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

Unbalanced Power Budget:

Bad coverage:

Interference:

DL interference area

AGCH lost

RACH

building

BTS

Channel Request

Access Grant

Max Path Loss UL

Max Path Loss DL

AGCH

RACH






1 � 3 � 30


RLE - Ghost RACH

� Synonyms: "Phantom/Ghost/Spurious/Dummy ... RACH"

� Channel request received, but not sent by a MS. Why?

� Electro-Magnetic Noise decoding within BTS

� Reception of channel request sent to a neighboring cell

� Reception of HO_ACCESS sent to a neighboring cell

� MS has already performed a HO to another cell

� MS has already reselected another cell

� MS is already busy replying to its first channel request

� Electro-Magnetic Noise from external interferer

Some tips to diagnose Ghost RACH:

1. Dummy Rach load depends on minimum level for decoding configured in BTS

2. During period with low real traffic (night), high rate of dummy RACH

3. For dummy RACH, the channel required has a random value of TA

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

Others have a known and predictable cause…






1 � 3 � 31


RLE - Ghost RACH Causes

� Example of a channel required message from a real ghost RACH

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.






1 � 3 � 32


RLE - Ghost RACH Causes [cont.]

� If Abis over Satellite, round-trip time (RTT) is about 540ms

� The MS autonomously repeats the Channel Request a second time

CHANNEL REQUEST (1)

CHANNEL REQUIRED (1)

CHANNEL REQUEST (2)Ch. Act.

Ch. Act. Ack.

IMM. ASSG. (1)

IMM. ASSIGNMENT (1)

IMM. ASSG. (2)

In this scenario:MC8c = 2MC8b = 2MC148 = 2MC02 = 1MC149 = 1

RTT

Compute the value of SDCCH_assign_fail_radio_rate= 1 / 2 = 50%

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

The CHANNEL REQUEST (2) is followed by Channel Required, Ch. Act, Ch Act Ack but they are not

represented here. Only the Immediate Assignment(2) is shown.

Round-Trip Delay






1 � 3 � 33


RLE – Co-BCCH/BSIC

� Subscriber not impacted (the real setup is performed elsewhere)

But MC149 incremented in far cell (SDCCH_assign_fail_radio_rate)

� A simple radio planning rule is sufficient to avoid the trouble

"2 cells must not have the same BCCH nearby"

TB Encrypted bits TB GP68,25336418

Access burst (AB)Synchronization sequence

Encrypted using the BSIC of the serving cell (3GPP TS45.003)

CHANNEL REQUEST (sent on BCCH frequency)

cell 001BCCH = 20BSIC = 4-1

cell 019BCCH = 20BSIC = 4-1

success !

failure !

Different BSIC will prevent this problem to happen.

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

● BCC: BTS Color Code

● NCC: Network Color Code

TB : Tail Burst (0,0,0)

GP : Guard Period






1 � 3 � 34


RLE – Co-TCH/BSIC

� Same idea… with worse impact

� MS doesn't send one HO Access … but four!

TB Encrypted bits TB GP68,25336418

Access burst (AB)Synchronization sequence

Encrypted using the BSIC

4 x HO ACCESS (sent on target frequency 24)

cell 001TRX1 = 14TRX2 = 24TRX3 = 26BSIC = 4-1

cell 019TRX1 = 24TRX2 = 28TRX3 = 30BSIC = 4-1

success !

failure !

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

● BCC: BTS Color Code

● NCC: Network Color Code






1 � 3 � 35

� The BSC receives a CHANNEL REQUEST and a SDCCH sub-channel is available. BSC allocates the SDCCH for that request.

� For how long is this SDCCH subchannel reserved?

� What is the impact on indicators of cell 019 ?


RLE – HO ACCCESS vs BCCH [cont.]

It is not reserved!

WI_xx

T3101 = 3 seconds (def.)

T3212

T9103

No impact

SDCCH_assign_req increases

SDCCH_assign_success decreases

SDCCH_assign_fail_radio_rate increases

SDCCH_assign_cong_rate increases

dsama

Texte surligné

dsama

Texte surligné

dsama

Texte surligné

dsama

Texte surligné






1 � 3 � 36


RLE - BSS Failure

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

� Knowing that:

� SDCCH_assign_request = MC04 + MC148

� SDCCH_assign_success = MC01 + MC02

� What is the formula for SDCCH_assign_fail_BSS_rate?





MC148 – (MC149) – (MC01 + MC02)

(MC04 + MC148)

attempt radio fail success

request

dsama

Texte surligné






1 � 3 � 37


RLE - Summary

REQUEST

Congestion

ATTEMPT

Radio access failure

SUCCESS

BSS problem

Preparation Failure

Execution Failure

invalid causesGSM valid causes

BSS problem

Request MC8C

GSM invalid causes unknownPreparation 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






1 � 3 � 38


RLE - Indicators

� In this graph, important informations are missing, which ones?

Congestion ! And the Unsuccess %

SDCCH_assign_cong

SDCCH_assign_fail_BSS

SDCCH_assign_fail_radio

SDCCH_assign_unsuccess_rate






1 � 3 � 39


Convention

REQUEST

ATTEMPT

SUCCESS

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

Preparation Phase

Execution Phase

Radio Fail

BSS Fail

SDCCH_assign

_fail_rate

Cong (BH, Max)

SDCCH_Load

Unavailability

Traffic Model

SDCCH_assign

_cong_rate

SDCCH_assign

_unsuccess_rate

DetailedKPI DetailedKPI

Fill up the table with indicators to monitor each phase






1 � 3 � 40


SDCCH Phase – Originated Call Success

� Once the SDCCH is allocated, it is used to pass "DTAP" messages

� Exchange of signalling between MS and MSC

DTAP messages

AUTHENTICATION REQUEST

AUTHENTICATION RESPONSE IMSI check

CIPHER MODE Command

CIPHER MODE Complete A5/x = ON

IDENTITY REQUEST

IDENTITY RESPONSE IMEI check

TMSI REALLOC Command

TMSI REALLOC Complete TMSI changed

CALL SETUP

CALL PROCEEDING other side = OKPaging of called party

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

DTAP - RR: Radio Resources

DTAP - MM: Mobility Management

DTAP - CC: Call Control

http://www.acacia-net.com/wwwcla/protocol/gsma.htm

dsama

Texte surligné






1 � 3 � 41


SDCCH Phase – Terminated Call Success

� Only the 2 last messages are changed


AUTHENTICATION RESPONSE

CIPHER MODE Command

CIPHER MODE Complete

CALL SETUP

CALL CONFIRM

IDENTITY REQUEST

IDENTITY RESPONSE

TMSI REALLOC Command

TMSI REALLOC Complete

DTAP messages

IMSI check

A5/x = ON

IMEI check

TMSI changed

other side = OK CALL PROCEEDING

to calling party

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

DTAP - RR: Radio Resources

DTAP - MM: Mobility Management

DTAP - CC: Call Control

http://www.acacia-net.com/wwwcla/protocol/gsma.htm






1 � 3 � 42


SDCCH Phase – Location Update Success

� Goal: Update VLR with new LAC, and reallocate TMSI in MS

CLASSMARK ENQUIRYCLASSMARK ENQUIRY

CLASSMARK CHANGECLASSMARK CHANGE CLASSMARK Update


AUTHENTICATION RESPONSE

CIPHER MODE Command

CIPHER MODE Complete

IDENTITY REQUEST

IDENTITY RESPONSE

LOCATION UPDATE Accept

TMSI REALLOC Complete

Optional

(BSS_SEND_CM_ENQUIRY)

Retrieve MS capabilities

DTAP messages

IMSI check

A5/x = ON

IMEI check

TMSI changed

BSS_SEND_CM_ENQUIRY

This flag is set by O&M to inform the BSC the conditions in which to send the CLASSMARK ENQUIRY

message to the MS.

The parameter has three defined values :

0 The CLASSMARK ENQUIRY is never initiated by the BSC

1 On reception of a LU REQUEST with ES IND flag is set to 0, the BSC will always initiate a CLASSMARK

ENQUIRY.

2 On reception of a LU REQUEST with ES IND flag is set to 0, the BSC will initiate the CLASSMARK

ENQUIRY only if algorithm A5/1 is not available (information available in MS classmark 1 IE sent in the

LOCATION UPDATING REQUEST).

The MS classmark data is collected and stored by the Alcatel BSS and is used in almost all the procedures

performed by the Alcatel BS.

The MS classmark data collected by the BSS classmark handling entity is:

- the MS revision level,

- the MS ciphering capabilities which are supported by the BSS,

- the MS frequency capabilities which are supported by the BSS,

- the MS RF power capabilities in every frequency band supported by the MS and the BSS,

- the MS classmark handling capabilities

- the MS Utran classmark






1 � 3 � 43


SDCCH Phase - Drops

� No dedicated counters for success case

� In case of failure, the word to use is "drop"

� It is a loss of connection during active transfer

� 3 causes of SDCCH drop:

� Radio problems when connected on SDCCH

� BSS problems

� Call lost during an SDCCH HO (handover failure without reversion to old channel)

SDCCH Drop Rate

SDCCH Drop BSS Rate

SDCCH Drop HO Rate

SDCCH Drop Radio Rate

Generally SDCCH handovers are disabled in the network since the average SDCCH duration is only around 2

to 3 seconds (parameter SDCCH_HO, with 0: SDCCH HO enabled, 1: SDCCH HO disabled)






1 � 3 � 44


SDCCH Phase - Radio Drop

MS BTS BSC MSCSDCCH Phase established

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

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

Cause : radio interface failure

SDCCH Drop Rate

SDCCH Drop BSS Rate

SDCCH Drop HO Rate


MC138

C180d

MC138 counts the number of SDCCH channel drops due to radio problems.

Radio problems can be due to coverage, interference and sometimes BSS dysfunction which is not detected

as a system alarm by the O&M Fault Management application.

MC138 is triggered when either:

1/ RADIOLINK TIMEOUT reaches "0" in the BTS (generating a Connection Failure Indication "Radio link

failure") Default setting = 18 SACCH = 8.64s.

2/ or, LApD link failure, after (N200+1) * T200 seconds (24 * 220ms = 5.28s)






1 � 3 � 45


SDCCH Phase - BSS Drop


MC137

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

Cause : O&M interventionCause : radio interface failure

SDCCH Drop Rate

SDCCH Drop BSS Rate

SDCCH Drop HO Rate


MC137

C180b or d

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

A BSS problem can be a BTS/BSC hardware or software failure, or an O&M action on the DTC board. It can

also be due to a problem on the Abis interface (due to Micro Wave transmission for instance).

Triggers:

1) LapD failure detected during the stable phase of an SDCCH transaction.

2) SDCCH was released due to 48.058 ERROR REPORT with any cause value being received during the stable

phase of an SDCCH transaction (ciphering problems, or any other problem detected by the TRX).

3) Telecom Supervisory module caused the call to be cleared.

4) SDCCH was released due to 0180 CLEAR_CMD message being received from BSSAP during the stable phase

of an SDCCH transaction : O&M has disabled the DTC






1 � 3 � 46


SDCCH Phase - HO drop


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

CLEAR REQUESTRadio Interface Message Failure (Alcatel)

SDCCH Drop Rate

SDCCH Drop BSS Rate

SDCCH Drop HO Rate


C180a

HO Failure & No Reversion to old channel � Drop !

T3103 expiry !! MC07

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

Internal inter-cell SDCCH handover: whenever the timer supervising the handover procedure (T3103)

expires.






1 � 3 � 47


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 phase

Normal release

Drop radio

Drop BSS

Drop HO

What are the cases of "normal release"?

End of the Location Update, IMSI Detach, SMS, SS procedures.






1 � 3 � 48


SDCCH Phase - Indicators

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:

GLOBAL Quality of service INDICATORS > SDCCH > Established phase

� GSDCDR: SDCCH drop rate (Global)

� GSDCDRR: SDCCH drop rate due to radio problem

� GSDCDBR: SDCCH drop rate due to BSS Problem

� GSDCDHR: SDCCH drop rate due to HO failure






1 � 3 � 49


SDCCH Phase - Exercise

� With K1205 (file PAIB29.REC)

1) Extract a location update (successful case)

2) Extract a transaction with an SDCCH drop.

� What is the cause of the failure?

� Is it possible to "guess" the type of transaction (OC, TC, LU, etc.)?

3) Extract an SDCCH drop for a different cause.

Time allowed:

15 minutes






1 � 3 � 50


TCH Assignment – Success Case

ASSIGNMENT REQUEST

PHYSICAL CONTEXT REQ.

PHYSICAL CONTEXT CNF.

CHANNEL ACTIVATION

CHANNEL ACTIVATION ACK.

ASSIGNMENT COMMAND

SABM (FACCH)

UA (FACCH)

ESTABLISH INDICATION

ASSIGNMENT COMPLETE

(FACCH)

ATER CONNECT REQUEST

ATER CONNECT ACK.

B11

Trr1

stop

T9108

stop

T9103

stop

T3107

stop

SDCCH

TCH

MC140a

MC703

MC140b

MC718

RMS31 (*)

RMS31: counted by the TRX, Whenever an ESTABLISH INDICATION message is received from the MS to

indicate the activation of a TCH channel for normal assignment or handover. Beware it is a RMS

counter, it is measured during the daily RMS campaign only.

B11 MR2: ATER CONNECT REQUEST / ACK in case of "IP BSS" and the call setup in a TDM BTS. The call will

still be carried by an AterMux nibble, rather than the IP backhaul.

dsama

Crayon

dsama

Crayon






1 � 3 � 51

RTCH_assign_request = REQUEST

RTCH_assign_command = ATTEMPT

RTCH_assign_success = SUCCESS


TCH Assignment – Phase Split

� This is a reduced view of the message flow, showing only messages triggering counters.

� Locate the preparation and the execution phase.

� Link them to their indicators.

ASSIGNMENT REQUEST

CHANNEL ACTIVATION

ASSIGNMENT COMMAND

ASSIGNMENT COMPLETE

(FACCH)

MC140a

MC703

MC140b

MC718

Preparation Phase

Execution Phase

� Which indicator is linked to MC703?

RTCH_Assign_Allocated

Preparation phase: preparation of the resources, ends with a message SENT over the Air interface

Execution phase: validation that the new radio channel allows communication in both directions

dsama

Crayon

dsama

Crayon

dsama

Crayon






1 � 3 � 52


TCH Assignment – MS Capabilities

ASSIGNMENT REQUEST

B11

MC701a

MC701b

MC701c

MC701d

MC701e

MC701f

MC701g

MC932

MC951

� Thanks to those counters, it is possible to count how many MS can support certain features

MS supports only FR

MS supports only FR & DR

MS supports EFR, FR & DR

MS supports AMR FR & AMR HR

Data calls

MS supports only EFR & FR

MS supports only EFR and/or HR

MS supports AMR WB GMSK

MS supports A5/3 ciphering

Most MS

Next-gen MS

Available in report

Alc_Mono_SpeechVersion_and_ChannelType

NPO

B11

Next-Gen: Next Generation






1 � 3 � 53


TCH Assignment - Congestion

� 4 causes of congestion ⇒ 4 counters. If no TCH available and …

a. Queue is disabled (by parameters) or not required by MSC

b. Queue is full (BTS_Q_LENGTH reached), or 9130 BSC's CCP is full

(MAX_TCH_PER_CCP is reached), or IP Abis is congested

c. Request stayed in the Queue too long (T11 or T11_FORCED expired)

d. Request is preempted by a high-priority request

� RTCH_assign_cong = MC812 = Σ MC612x

ASSIGNMENT REQUEST

ASSIGNMENT FAILURE

"No Radio Resource Available"

no TCH available

in the cell

MC612a/b/c/d

MC140b

B11

B11 MR2

MC612

MC612

MC612

MC612






1 � 3 � 54


TCH Assignment – Exercise

� Using NPO or the Indicator Dictionary, propose indicators & methods to start the investigation in a cell.

� RTCH_assign_cong_rate = 15%

hardware problem? too much traffic?

TCH availability

OMC-R Alarms

TCH traffic BH per TRX

TCH duration avg per TRX

TCH traffic BH per TRX

TCH traffic BH per cell

RTCH traffic load

Ratio of HR

Ratio of AMR HR

TCH Queuing indicators

Solutions: Solutions:

Exchange TRX

Activate HR

Share load with other cells

Add TRX

Activate HR

Share load with other cells

Check importance of problem thanks to:

RTCH_assign_cong_rate_BH & Hourly RTCH_assign_cong_rate

If real problem (not temporary peak), then 2 main possible problems

1

2 3

dsama

Zone de texte

Check importance of problem thanks to: RTCH_assign_cong_rate_BH & hourly RTCH_assign_cong_rate

dsama

Zone de texte

hardware problem? tch availability OMC-R Alarms tch traffic BH per TRX tch duration avg per TRX Solutions: Exchange TRX Activate HR Share load with other cells

dsama

Zone de texte

too much traffic? tch traffic BH per cell rtch traffic load Ratio of HR Ratio of AMR HR tch queing indicators Solutions: Add TRX Activate HR Share load with other cells






1 � 3 � 55


TCH Assignment - Radio Failure in TCH Uplink

ASSIGNMENT REQUEST



CHANNEL ACTIVATION


ASSIGNMENT COMMAND

SDCCH

MC140a

MC703

MC140b T3107

stop

MC746b ASSIGNMENT FAILURE

Radio interface failure w/ rev

Trr1

expiryASSIGNMENT REQUEST

SDCCH in DL still

probably OK

SABM (FACCH)

TCH

retransmitted up to N200_LE times

ASSIGNMENT FAILURE

SDCCH SABM

UA


xx

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

The MC746B counter is implemented at TRX level.

In case of TCH access failure, the MS will try to revert back to the SDCCH channel. Whether it succeeds in

reverting to the SDCCH or not the call establishment fails. On the other hand, some MSCs may resend the

ASSIGNMENT REQUEST again.






1 � 3 � 56


TCH Assignment - Radio Failure in TCH Downlink

ASSIGNMENT REQUEST



CHANNEL ACTIVATION


ASSIGNMENT COMMAND

SDCCH

MC140a

MC703

MC140b T3107

stop


Radio interface failure w/ rev

Trr1


SDCCH in DL still

probably OK

SABM (FACCH)

TCH

ASSIGNMENT FAILURE

SDCCH SABM

UA


SABM (FACCH)

x N200_LE

UAx

UAx


RMS31 (*)






1 � 3 � 57


TCH Assignment - Radio Failure at T3107 expiry

ASSIGNMENT REQUEST



CHANNEL ACTIVATION


ASSIGNMENT COMMAND

SDCCH

MC140a

MC703

MC140b T3107

(14s)

expiry


Radio interface failure

Trr1


SDCCH in DL still

probably OK

SABM (FACCH)

TCH

SDCCH SABM

SABM (FACCH)

x N200_LE

x

xSABM

x

x

x N200_LE

dsama

Zone de texte

SABM: Set Asynchronous Balanced Mode






1 � 3 � 58


TCH Assignment - BSS Problem

� No specific counter

� Computed from the missing data

� BSS Problems during preparation phase

= Requests – Attempts – Congestion Failures

= MC140a – MC140b – MC812

� Probable cause: NSS or BSS software problems

� BSS Problems during execution phase

= Attempts – Success – Radio Failures

= MC140b – MC718 – MC746b

� Probable cause: Hardware problem, O&M intervention

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






1 � 3 � 59


TCH Assignment - Counters

� TCH assignment counters

Congestion

ATTEMPT

Radio access failure

SUCCESS

BSS problem

Preparation Failure

Execution Failure

REQUEST

BSS problem

TCH 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

dsama

Texte surligné

dsama

Texte surligné






1 � 3 � 60


TCH Assignment - Indicators

Report: Alc_Mono_Call






1 � 3 � 61


TCH Assignment - Exercise

� TCH assignment failure and BSC

� With K1205 (file PAIB29.REC)

1) Find and extract a case of TCH congestion (if any).

2) Find and extract a case of Assignment Failure due to Radio Problem (if any).

Time allowed:

15 minutes






1 � 3 � 62

3 Key Performance Indicators






1 � 3 � 63


Reminder

� Global Indicators are

� A set of indicators selected by Alcatel-Lucent

� Useful to monitor the overall network

� What are the user and or system impacts if a KPI is bad?






1 � 3 � 64


SDCCH Congestion Rate

� SDCCH CONGESTION rate: may have low impact for subscriber

� Failure impacting the user only after 3 subsequent congestion failures

� Otherwise, only some extra delay for call establishment

� Less than 1 second without immediate_assign_reject

� Can be longer with immediate_assign_reject (but usually short values are used for call request)

GSDNACGR

Reference name

Check SDCCH Erlang… if not critical:

- SDCCH availability/allocation

problem,

- Or HO access on a nearby cell side

effect or interference on the carrier

handling SDCCH (the last 2 can lead

to high rate of «phantom RACH »)

Comments

%5%(MC04) / SDCCH ASSIGN

REQUESTSSDCCH ASSIGN CONG RATE

UnitThresholdFormulaeIndicator

(G) means that the indicator is GSM

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






1 � 3 � 65


SDCCH Congestion Rate [cont.]

�SDCCH CONGESTION rate

SDCCH Assign Congestion - CELL2G: BA1046_1 (128/10461) ( 220/F05/128/10461 ) - 02/03/2009 00 00:00 To 02/03/2009 23 23:00 (Working Zone: Global - Medium)

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

00 0

0:00

01 0

1:00

02 0

2:00

03 0

3:00

04 0

4:00

05 0

5:00

06 0

6:00

07 0

7:00

08 0

8:00

09 0

9:00

10 1

0:00

11 1

1:00

12 1

2:00

13 1

3:00

14 1

4:00

15 1

5:00

16 1

6:00

17 1

7:00

18 1

8:00

19 1

9:00

20 2

0:00

21 2

1:00

22 2

2:00

23 2

3:00

nb

0.00%

0.01%

0.01%

0.02%

0.02%

0.03%

%

Congestion

Request

% Congestion


GLOBAL Quality of service INDICATORS > SDCCH > Assignment phase

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






1 � 3 � 66


SDCCH Failure Rate

� SDCCH FAILURE rate: may have low impact for subscriber

� Failure impacts the user only after 3 subsequent failures

� In this indicator, only failure due to loss of radio link or failure due to "unknown" causes are counted

� Unknown causes are called "BSS", and generally happen because of hard- or soft-ware failures

GSDNAFLR

Reference name

Check SDCCH Erlang… if not critical:

- SDCCH availability/allocation

problem,

- Or HO access on a nearby cell side

effect or interference on the carrier

handling SDCCH (the last 2 can lead

to high rate of «phantom RACH »)

Comments

%5%MC149 +

SDCCH_assign_fail_BSS /

SDCCH ASSIGN REQUESTS

SDCCH ASSIGN FAIL RATE


(G) means that the indicator is GSM

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






1 � 3 � 67


SDCCH Failure Rate [cont.]

� SDCCH FAILURE rate

SDCCH assignment failure - CELL2G: BA1046_1 (128/10461) ( 220/F05/128/10461 ) - 02/03/2009 00 00:00 To 02/03/2009 23 23:00 (Working Zone: Global - Medium)

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

00 0

0:00

01 0

1:00

02 0

2:00

03 0

3:00

04 0

4:00

05 0

5:00

06 0

6:00

07 0

7:00

08 0

8:00

09 0

9:00

10 1

0:00

11 1

1:00

12 1

2:00

13 1

3:00

14 1

4:00

15 1

5:00

16 1

6:00

17 1

7:00

18 1

8:00

19 1

9:00

20 2

0:00

21 2

1:00

22 2

2:00

23 2

3:00

nb

.0%

2.0%

4.0%

6.0%

8.0%

10.0%

12.0%

%

Fail - BSS

Fail - Radio

Success

% Fail


GLOBAL Quality of service INDICATORS > SDCCH > Assignment phase






1 � 3 � 68


SDCCH Drop Rate

GQSSDCDR

Reference name

Drop radio + Drop HO + Drop BSS

Comments

%4%(MC138 + MC07 + MC137) /

SDCCH ASSIGN SUCCESS

SDCCH_drop_rate


� SDCCH DROP RATE

� Rate of dropped SDCCH (SDCCH is established for any transaction OC, TC, LU,etc.)

In a dense network, SDCCH drop rate should be lower than 1%. Indeed the probablity to drop a radio link

when the MS is on SDCCH is less than on TCH since the SDCCH phase is shorter (less than 5 seconds) than

TCH phase (duration of a call = several tens of seconds).

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






1 � 3 � 69


SDCCH Drop Rate [cont.]

� SDCCH Drop Rate

SDCCH Drop - CELL2G: 02/03/2009 00 00:00 To 02/03/2009 23 23:00 (Working Zone: Global - Medium)

0

10

20

30

40

50

60

00 0

0:00

01 0

1:00

02 0

2:00

03 0

3:00

04 0

4:00

05 0

5:00

06 0

6:00

07 0

7:00

08 0

8:00

09 0

9:00

10 1

0:00

11 1

1:00

12 1

2:00

13 1

3:00

14 1

4:00

15 1

5:00

16 1

6:00

17 1

7:00

18 1

8:00

19 1

9:00

20 2

0:00

21 2

1:00

22 2

2:00

23 2

3:00

nb

0.%

0.5%

1.%

1.5%

2.%

2.5%

%

Drop - BSS

Drop - HO

Drop - Radio

% Drop






1 � 3 � 70


RTCH Assign Unsuccess Rate

� RTCH ASSIGN UNSUCCESS rate:

� Rate of unsuccessful RTCH seizures for normal assignment purpose:

� Congestion during Call Setup (not during Handover !!)

� Radio problem

� BSS problems

GTCNAUR

Reference nameComments

%3%(RTCH ASSIGN REQUESTS –

RTCH ASSIGN SUCCESS) /

RTCH ASSIGN REQUESTS

RTCH_assign

unsuccess_rate


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 tr 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 lis 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 tr 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 lis 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 tr 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 lis 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 tr 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 lis 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






1 � 3 � 71


RTCH Assign Unsuccess Rate – Preparation Phase

� RTCH Assign Preparation

RTCH assign preparation - CELL2G: 02/03/2009 00 00:00 To 02/03/2009 23 23:00 (Working Zone: Global - Medium)

0

200

400

600

800

1000

1200

1400

00 00

:00

02 02

:00

04 04

:00

06 06

:00

08 08

:00

10 10

:00

12 12

:00

14 14

:00

16 16

:00

18 18

:00

20 20

:00

22 22

:00

nb

0.00%

1.00%

2.00%

3.00%

4.00%

5.00%

6.00%

7.00%

%

Prep Fail BSS

Congestion

Request

% Prep Fail BSS

% Congestion






1 � 3 � 72


RTCH Assign Unsuccess Rate – Execution Phase

� RTCH Assign Execution

RTCH assign execution - CELL2G: 02/03/2009 00 00:00 To 02/03/2009 23 23:00 (Working Zone: Global - Medium)

0

200

400

600

800

1000

1200

00 00

:00

02 02

:00

04 04

:00

06 06

:00

08 08

:00

10 10

:00

12 12

:00

14 14

:00

16 16

:00

18 18

:00

20 20

:00

22 22

:00

nb

0.%

0.5%

1.%

1.5%

2.%

2.5%

%

Exe Fail BSS

Fail Radio

Success

% Exe Fail BSS

% Fail Radio






1 � 3 � 73


Cell Congestion Rate

4 Different Indicators: Which one is the KPI?

� Subscriber is directly impacted by TCH NA Congestion, but not by HO Congestion

� Indeed, a HO congestion leads to another HO attempt, not to a call failure

� Therefore, RTCH_Assign_Cong_Rate is the best image of "end user"-congestion

GTCAHCGRNA + Inc HO

(TCH intra & intercell)

3%(RTCH_assign_cong + RTCH_HO_cong) /

(RTCH_assign_request + RTCH_HO_request)

RTCH_cong_rate

GTCNACGRNormal Assignment3%RTCH_assign_cong / RTCH_assign_requestRTCH_Assign_Cong_Rate

GTCHOCGRIncoming HO

(TCH intra & intercell)

3%RTCH_HO_cong / RTCH_HO_requestRTCH_HO_Cong_Rate

GQSCGR

Reference name

Inc HO takes into

account SDCCH & TCH

intercell HO

Comments

3%(RTCH_assign_cong + HO_Inc_cong) /

(RTCH_assign_request + RTCH_HO_allocated

+ HO_Inc_cong)

Call_cong_rate

Threshold

FormulaeIndicator

Used in "TCH Assign Unsuccess Rate" calculation

This counter intends to give a measurement of the TCH congestion of the whole network.

It is implemented on the Alcatel-Lucent tools but other indicators can be defined.

� RTCH_assign_cong new:MC812, old:MC812

� HO_Inc_cong = HO_Inc_MSC_cong + HO_Inc_BSC_cong

� RTCH_assign_request = new:MC140a-(MC142e+MC142f), old:MC140a-(MC142e+MC142f)

� RTCH_HO_allocated = new:MC15b + MC15a, old:MC15b + MC15a

� HO_Inc_cong = HO_Inc_MSC_cong + HO_Inc_BSC_cong

Note: The congestion counted in those indicators is linked to the following issues:

1) all TCH are busy and no TCH could be allocated for the request

2) or the CCP board in the MX-BSC reaches the limit MAX_TCH_PER_CCP (default = 1000)

MC926 : Number of TCH channel allocation rejected for cause : Maximum TCH processing capacity of CCP

reached

Whenever a TCH cannot be allocated due to the TCH processing capacity of CCP reaches the limit defined by

the MAX_TCH_PER_CCP parameter.






1 � 3 � 74


Call Setup Success Rate

MS BTS BSC MSC

CALL PROCEEDING

ESTAB IND (CM_Serv_Req)


Authentification Procedure

Ciphering Procedure

SETUP

Assignment Procedure

ALERTING

CONNECT ACK.

CONNECT

SCCP CON REQ (CM_Serv_Req)

SCCP CON CONFIRM

Identification Procedure

ASSIGNMENT REQUEST

ASSIGNMENT COMPLETE

SDCCH assignment success

Normal assignment success

SDCCH Dropincl. Call, SMS, LUIMSI Detach, etc

TCH AssignUnsuccess(for normalassignment only)

GQSEECSSR will always be smaller than the GQSCSSR, because all failures due to NSS are now taking into

account. They were not counted in the CSSR.






1 � 3 � 75


Call Setup Success Rate [cont.]

� CALL SETUP SUCCESS rate: Rate of calls going until TCH successful assignment, that is not interrupted by SDCCH DROP neither by Assignment failures

� The second most important indicator

� Used to compare PLMN

� Subscriber: call not established at the first attempt

� Beware: call setup failures due to a lack of coverage are not taken into account in this indicator!!

� No way to quantify them (as there is no initial access)

GQSCSSR

Reference name

SDCCH assignment

unsuccesses are not

considered in CSSR as :

• ghost (spurious) RACH

cannot be discriminated

from a real access failure

• effect of re-attempts

performed autonomously by

the MS cannot be quantified

Comments

%95%(1 – SDCCH DROP RATE) * (1 - TCH

ASSIGN UNSUCCESS RATE)

Call_setup_success_rate

UnitThreshol

dFormulaeIndicator

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.

dsama

Texte surligné






1 � 3 � 76


Call Success Rate

� CALL SUCCESS rate: Rate of calls going until normal release , that is not interruptedby SDCCH DROP, neither by Assignment Failures nor by CALL DROP

� 1 call success =

� 1 call successfully established

� Without any call drop

GQSCCR

Reference name

Comments

%92%(CALL SETUP SUCCESS RATE)

* (1 – CALL DROP RATE)

Call_success_rate

UnitThresho

ldFormulaeIndicator

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






1 � 3 � 77


End to End Call Setup Success Rate

MS BTS BSC MSC

CALL PROCEEDING

ESTAB IND (CM_Serv_Req)


Authentification Procedure

Ciphering Procedure

SETUP

Assignment Procedure

ALERTING

CONNECT ACK.

CONNECT

SCCP CON REQ (CM_Serv_Req)

SCCP CON CONFIRM

Identification Procedure

ASSIGNMENT REQUEST

ASSIGNMENT COMPLETE

SDCCH assignment success

Normal assignment success

E2E CSSR

GQSEECSSR will always be smaller than the GQSCSSR, because all failures due to NSS are now taking into

account. They were not counted in the CSSR.






1 � 3 � 78


End to End Call Setup Success Rate [cont.]

� End to End CSSR : The successes of call setup phase (between the SDCCH assignment success and the TCH assignment success) taking into account all what can happen during this phase between MS and MSC

� View of the call setup success rate from the end user point-of-view.

� Have a global view of the end-user perceived quality of their GSM network, whatever the problems encountered. Fastest detection and correction of problems would be possible, leading to improved quality.

GQSEECSSR

Reference

name

%91%(RTCH_assign_success + DR_Out_internal_success +

DR_Out_external_success)

/ (MT_SDCCH_assign_success - SDCCH_SMS_MT_PP_connection+

SDCCH_traffic_Call_reestab + SDCCH_traffic_lu_for +

SDCCH_traffic_other_mo + SDCCH_traffic_moc)

End_to_End_call_setup_success_rate


hMCfMCdMCeMCMCMC

fMCeMCMC

0202020219101

142142718

++++−++

MC718 : Number of TCH (in HR or FR usage) normal assignment successes, per TRX (ASSIGNMENT COMPLETE).

MC142e : Number of outgoing normal & forced internal directed retry (towards a TCH channel in HR or FR

usage) successes.

MC142f : Number of outgoing normal & forced external directed retry (towards a TCH channel in HR or FR

usage) successes.

MC01 : Number of immediate assignment plus SDCCH normal assignment successes for Mobile Terminating

procedure (ESTABLISH INDICATION w/ PAGING RESPONSE)

MC191 : Number of Mobile Terminating SMS connections on SDCCH.

MC02e : ESTABLISH INDICATION w/ CM RE-ESTABLISHMENT REQUEST

MC02d : ESTABLISH INDICATION w/ LOCATION UPDATING REQUEST with FORWARDING

MC02f : ESTABLISH INDICATION w/ unknown causes but forwarded to MSC (= leading to TCH establishment)

MC02h : ESTABLISH INDICATION w/ CM SERVICE REQUEST Normal Call or Emergency Call






1 � 3 � 79


Alc_Mono_Call

� CALL SETUP SUCCESS RATE

� CALL SUCCESS RATE

� END TO END CALL SETUP SUCCESS RATE


GLOBAL Quality of service INDICATORS > Call statistics > Call success

� GQSCSSR: Call setup success rate (Global)

� GQSCCR: Call success rate (Global)

� GQSEECSSR: End to End Call Setup Success Rate (Global)






1 � 3 � 80


Differences between CSSR and E2ECSSR

� The main reasons for differences are:

1. The MSC doesn't send the ASSIGNMENT REQUEST after CALL PROCEEDING

2. SDCCH Drops mostly during Location Updates & SMS & IMSI Detach

DegradedNot impacted

XE2E CSSR

XLegacy CSSR

DegradedNot impacted

XE2E CSSR

XLegacy CSSR






1 � 3 � 81









1 � 3 � 82

End of ModuleDetailed Indicators






Module 4Handover Indicators









EVOLIUM Base Station Subsystem � BSS B10 Introduction to Quality of Service and Traffic Load MonitoringGSM QoS Monitoring � Handover Indicators

1 � 4 � 2

Blank Page


First editionLast name, first nameYYYY-MM-DD01


Document History






1 � 4 � 3

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






1 � 4 � 4








1 � 4 � 5

Table of Contents


1 Handovers Overview 7Description 8Types 9

2 Intra-Cell Handovers 10Intracell HO - Success 11Failure Causes 12Failure - Congestion 13Failure - Radio Failure with ROC 14Failure - Radio Failure with Drop 15Failure – Other Drops "BSS" 16Main Counters 17

3 Internal Intercell Handovers 18Internal HO – Success (Async) 19HO COMMAND message 20Incoming Internal HO - Failures 21Incoming Internal HO - Congestion 22Incoming Internal HO - Radio Failure 23Incoming Internal HO - Counters 24Incoming Internal HO - Indicators 25Outgoing Internal HO - Failures 26Outgoing Internal HO - Radio Failure ROC 27Outgoing Internal HO - Radio Failure Drop 28Outgoing Internal HO - Counters 29Outgoing Internal HO - Indicators 30Intra-Cell HO / Internal HO - Exercise 31

4 External Intercell Handovers 32External HO - Success 33External HO - Failures 34Incoming External HO - Congestion 35Incoming External HO – TTCH (CIC) Congestion 36Incoming External HO - Radio Failure 37Incoming External HO - Counters 38Incoming External HO - Indicators 39Outgoing External HO - Failures 40Outgoing External HO - Radio Failure with ROC 41Outgoing External HO - Radio Failure Drop 42Outgoing External HO - Counters 43Outgoing External HO - Indicators 44External HO - Exercise 45

5 Handovers QoS per Adjacency 46Type 180 Counters 47Type 180 Indicators 48Type 26: TCH outgoing handover per adjacency 50Type 27: 2G TCH incoming handover per adjacency 51Type 27 Indicators 52

6 Inter-PLMN and Inter-RAT 53Inter-PLMN HO Description 54Inter-PLMN Indicators 55

2G-3G Indicators 567 Key Performance Indicators 57Handover Cause Distribution 58Handover Standard Cause Distribution 59Handover Cause Distribution 60Outgoing Handover Success Rate 61Incoming Handover Success Rate 62






1 � 4 � 6



Handover Failure Main Causes 63






1 � 4 � 7

1 Handovers Overview






1 � 4 � 8

� Handovers are detected & prepared by the BSC

� Algorithms are checked

� Radio resources are allocated

� MS moves from 1 TCH in the Serving Cell to 1 TCH in the Target Cell


Description

BSC

CELL (S)

CELL (T)

1 Radiolink Measurements

BTS

2 Active Channel Preprocessing

4

HO Detection

Candidate Cell Evaluation

5 HO Preparation

6 HO Execution

3

channel activation

handover command

note: Handovers are not only from TCH to TCH:

HO SDCCH to SDCCH (SDCCH HO)

HO SDCCH to TCH (=directed retry)






1 � 4 � 9


Types

Intracell IntercellNew TCH is in another TRX of the current cell

New TCH is in another cell

Internal ExternalServing and Target cells belong to the same BSC

(intra-BSC)

Serving and Target cells belong to different BSCs

(inter-BSC)

Incoming OutgoingPoint of view from the

target cellPoint of view from the

serving cell

Synchronous Async.Seving and Target cells

are synchronizedServing and Target cells are not synchronized

Emergency Better CellIf the MS doesn't leave the current channel, a call drop will occur

The Target cell is betterthan the Serving cell






1 � 4 � 10

2 Intra-Cell Handovers






1 � 4 � 11


Intracell HO - Success

MS Cell BSC *TC* MSC

(detection of intracell HO)

Physical Context Request

Physical Context Confirm

Channel Activation (new ch)

Channel Act. Ack (new ch)

Assignment CommandAssign Command

SABM (new ch)

UA (new ch)

Assign Complete (new ch)Assign Complete

Handover Performed

RF Channel Release

RF Channel Release Ack

Establish Indication (new ch)

T9108

T9103

T3107

MC870

MC662

MC871

BSC Shared DTM Info Indicationonly for DTM-capable MS

MFS

Both SDCCH and TCH are counted together.

The T3107 timer is also used as the guard timer of the channel change procedure during an intra cell handover.

The default value for T3107 is 14 seconds.

The BSC will send “BSC Shared DTM INFO Indication” to inform the MFS the successful end of the procedure if

the conditions below are fulfilled:

� EN_DTM = enabled

� The MS is DTM capable

by default : T3107 = 14sec






1 � 4 � 12


Failure Causes

� Handover Preparation:

� Congestion HO_Cell_cong

� Preparatio Failure HO_Cell_prep_fail *

� Handover Execution:

� Reversion to old channel HO_Cell_ROC

� Drop radio HO_Cell_drop_radio

� Drop due to BSS problem HO_Cell_drop_BSS *

(*) No specific counter






1 � 4 � 13


Failure - Congestion

MS Cell BSC

Measurement ResultMeasurement Report

(detection of intracell HO) MC870

(no free channel) MC561 MC101

TCH / SDCCH

MC561:

• In MX BSC, this counter is incremented whenever an intra-cell TCH handover cannot be performed due to the TCH processing capacity of CCP reaches the limit defined by the MAX_TCH_PER_CCP parameter. In this case, MC926 is also incremented by one.

From B7, MC561 replaces MC61 (B6).

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






1 � 4 � 14


Failure - Radio Failure with ROC

MS Cell BSC

Assignment CommandAssign Command (old)

SABM (new)

UA (new)

Assign Failure (old) Assign Failure

RF Channel Release (new)

RF Channel Release Ack (new)

Establish Indication

T3107

MC667

MC871

X

SABM (new)

UA (new)X

T200_TF

200ms

N200_TTF

try

times

SABM (new)

UA (new)X

200ms

etc etc etc

Physical Context Request (new)

Physical Context Confirm (new)

stop

In this example, the Downlink path on the new channel is faulty (interference, path unbalance …).

It is also possible the MS immediately sends an Assign Failure (without even attempting to connect to the new

channel).

N200_TTF = 34

T200_TF = 200ms

200 * 35 = 7seconds

MC667 = C107 (sdcch intracell ho fail roc) + C67 (tch intracell ho fail roc)






1 � 4 � 15


Failure - Radio Failure with Drop

MS Cell BSC

Assignment CommandAssign Command (old) T3107MC871?

?

MC663Channel release ofold and new channels

MC663 = C103 (sdcch) + C63 (tch)






1 � 4 � 16


Failure – Other Drops "BSS"

� Based on missing successes:

HO_Cell_drop_BSS =

HO_Cell_allocated - HO_Cell_success - HO_Cell_drop_radio - HO_Cell_ROC

� Another counter is linked to various causes of drops during HO preparation and execution phases:

MC14a (Call_drop_HO_Prep_Exec_BSS_failure) is incremented when :

� TCH Channel Activation is acknowledged negatively

� Channel Activation procedure (T9103) expires

� LapD failure, or Abis failure, or BSC boards failure

� 48.058 ERROR REPORT message with a cause value of "O&M intervention" or "message sequence error" is received on Abis interface from either the serving or the target cell

� 48.058 CONNECTION FAILURE INDICATION message with a cause value of "remote transcoder failure" during the Channel Activation procedure

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






1 � 4 � 17


Main 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

DROP BSS

SUCCESS

BSS PB

Preparation Failure

Execution Failure






1 � 4 � 18

3 Internal Intercell Handovers






1 � 4 � 19


Internal HO – Success (Async)

MS Target Cell BSC MSC

(detection of intercell HO)

Channel Activation (new ch)

Channel Act. Ack (new ch)

(opt) TFO Modification Req

HO Access * 4

UA (new ch)

Assign Complete (new ch) Handover Complete

Handover Performed

HO Detection

T9103

BSC Shared DTM Info Indicationonly for DTM-capable MS

MFS

Serving Cell

HO Command

Establish IndicationSABM (new ch)

(old channel release)

MC871 T3103

MC655a MC830

MC652

MC660

MC656

speech

speechTCH

TCH

MC830=C230 (tch) + C330 (sdcch)

After the HO PERFORMED is sent to the MSC.

� if DTM is enabled in the old cell, it sends a BSCGP BSC shared DTM info indication (CS_Flag = 0) to the MFS.

� if DTM is enabled in the new cell, it send a BSCGP BSC shared DTM info indication (CS_flag = 1) to the MFS.

The MFS in the old cell deletes the MS context and creates an MS context according to the information

received in the BSCGP BSC shared DTM info indication.

In case of Sync HO, the HO COMMAND contains a valid timing advance value, so that the MS will use this timing

advance in the target cell.

If the HO is not sync, then the HO COMMAND indicates that the HO is async, and the MS will send the HO

ACCESS with TA=0. The target BTS will need to compute the TA.

dsama

Barrer

dsama

Texte de remplacement

LIKE RACH, FOR ACCESS TO THE NEW CELL






1 � 4 � 20


HO COMMAND message

� The TCH in the Target cell is fully described in the HO Command

� BCCH, BCC, NCC

� TCH Frequency (or Frequency Hopping MA List, MAIO, HSN, etc.)

� TS Number

� Ciphering

� Speech Codec (only for phase 2 MS)

� Timing Advance information (if Sync HO)

Serving CellHO Command

TCH






1 � 4 � 21


Incoming Internal HO - Failures

� Causes of Failures :

� Handover procedure from the target cell point of view


� Congestion: no RTCH available in the target cell

� "Other" problem (no specific counter)


� Radio problem: the MS fails to access the new channel� which can lead to a "drop" or a "reversion to old channel" (cf. outgoing indicators)

� BSS problem (no specific counter)






1 � 4 � 22


Incoming Internal HO - Congestion

MS Serving Cell Serving BSC MSC

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

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






1 � 4 � 23


Incoming Internal HO - Radio Failure

� MS access problem

MS serving cell target cell BSC MSCMEAS REP

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

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

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

<------------------------------------------------------------- stop T3105HANDOVER COMPLETE

----------------------------------------------------- - - - -XSABM

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






1 � 4 � 24


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






1 � 4 � 25


Incoming Internal HO - Indicators

HO_Inc_BSC_request

HO_Inc_BSC_success

HO_Inc_BSC_allocated HO_Inc_BSC_cong HO_Inc_BSC_prep_fail

HO_Inc_BSC_fail_radio HO_Inc_BSC_fail_BSS


Handover Statistics INDICATORS > Incoming handover > Incoming Intra BSC

� GHOIBEFR: efficiency of the incoming internal HO execution

� GHOIBCGR: rate of incoming internal HO failures due to congestion

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

� GHOIBFLRR: rate of incoming internal HO failures due to radio problems

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






1 � 4 � 26


Outgoing Internal HO - Failures

� Cases of Failures:

� Handover procedure from the serving cell point of view


� Preparation Failures (no details)


� radio problem: the MS reverts to the old channel

� radio problem: the MS drops







1 � 4 � 27


Outgoing Internal HO - Radio Failure ROC



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


SABM-------------------------------------------------------------> ESTABLISH INDICATION

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

HANDOVER COMPLETE----------------------------------------------------- - - - -X

SABM-----------------------> ESTABLISH INDICATION

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

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







1 � 4 � 28


Outgoing Internal HO - Radio Failure Drop

� clear_request: ask the MSC to release the connection

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


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


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


MC660SABM

----------x

T3103 expiryMC658

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

Clear_command

Release of old and new TCH <------------------------






1 � 4 � 29


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






1 � 4 � 30


Outgoing Internal HO - Indicators

HO_Out_BSC_request

HO_Out_BSC_success

HO_Out_BSC_required HO_Out_BSC_prep_fail

HO_Out_BSC_drop_radio HO_Out_BSC_drop_BSSHO_Out_BSC_ROC


Handover Statistics INDICATORS > Outgoing handover > Outgoing Intra BSC

� GHOOBRQR: efficiency of the outgoing internal HO preparation

� GHOOBEFR: efficiency of the outgoing internal HO execution

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

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

� GHOOBCDR: rate of incoming internal HO failures with drop (radio + BSS)






1 � 4 � 31


Intra-Cell HO / Internal HO - Exercise

� With K1205, find in the PAIB29.REC file:

1) One case of intra-cell failure with reversion

2) One case of Internal handover success� Identify the target cell

� Identify the serving cell (in CR for call establishment)

3) One case of Internal handover failure with reversion

4) One case of Internal handover failure without reversion

Time allowed:

15 minutes






1 � 4 � 32

4 External Intercell Handovers






1 � 4 � 33


External HO - Success

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 ------ MC642MC646 Cause: HO_SUCCESSFUL

Release of TCH Stop T8

MC462A

MC462B

MC462C

MC463A

MC463B

MC463C

T7 and T8 are timers used to monitor the handover management. T7 : timer between HOREQ and HOCMD, T8 : timer between HOCMD and HOCMP.

Both SDCCH and TCH are counted together.

From B7, MC645A replaces MC645 of B6.

MC645a is only counting HANDOVER REQUIRED messages that are linked to a handover trial and not those that are linked to the update of the candidate cell list for handover / directed retry. This is leading to a more accurate computation of the External outgoing HO success rate.Only Outgoing inter PLMN HO is allowed.

6 counters provide information for "Inter-PLMN HO" (Incoming and Outgoing) (From B8)

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

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

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

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

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

� MC463c (equivalent of MC642 for intra PLMN external HO)Number of inter-PLMN TCH incoming handovers or directed retry successes: HANDOVER COMPLETE received from the MS on Abis for an external TCH HO or an external DR triggered towards the target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.

Note than all other (previous) counters related to HO continue to be based on Intra PLMN only.

Start T7

Stop T7






1 � 4 � 34


External HO - Failures

� Cases of Failures, from the target cell perspective (incoming):

HO_Inc_MSC_request

HO_Inc_MSC_success

HO_Inc_MSC_allocated

HO_Inc_MSC_fail_BSSHO_Inc_MSC_fail_radio

HO_Inc_MSC_cong HO_Inc_MSC_no_cic_alloc HO_Inc_MSC_prep_fail

(deduced)

(deduced)

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

successes.






1 � 4 � 35


Incoming External HO - Congestion


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

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

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

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

- RTCH timeslot congestion

- "target" Mx-BSC CCP board capacity exceeded

- With Abis over IP (B11 MR3), when the Abis is congested.

(note: TDM Abis congestion cannot be seen with this counter)






1 � 4 � 36


Incoming External HO – TTCH (CIC) Congestion


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

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

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

( < -HO_REQUIRED_REJECT-)






1 � 4 � 37


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.






1 � 4 � 38


Incoming External HO - Counters

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

MC41bno CIC alloc

NO CIC ALLOC

MC541a+MC81






1 � 4 � 39


Incoming External HO - Indicators


Handover Statistics INDICATORS > Incoming handover > Incoming Inter BSC

� GHOIMEFR: efficiency of the incoming external HO execution

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

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

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

� GHOIMFLRR: rate of incoming external HO failures due to radio problems

� GHOIMFLBR: rate of incoming external HO failures due to BSS during the execution phase

Inter PLMN Incoming External HO Indicators (from B8)

An indicator is created for each counter:

� REQUESTS

� ATTEMPTS

� SUCCESS

In addition, these indicators show:

� the success rate of incoming inter-PLMN HOs,

� the ratio of incoming inter-PLMN HO to incoming intra-PLMN and inter-PLMN HO.






1 � 4 � 40


Outgoing External HO - Failures

� Cases of Failures (Outgoing)


� No detail available, only generic "preparation failures"





HO_Out_MSC_required

HO_Out_MSC_success

HO_Out_MSC_request

HO_Out_MSC_drop_BSSHO_Out_MSC_ROC

HO_Out_MSC_prep_fail

(deduced)

(deduced)

HO_Out_MSC_drop_radio






1 � 4 � 41


Outgoing External HO - Radio Failure with ROC



----------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 channelRelease of connection






1 � 4 � 42


Outgoing External HO - Radio Failure Drop

� In this case, no reversion to old channel detected



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







1 � 4 � 43


Outgoing External HO - Counters

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






1 � 4 � 44


Outgoing External HO - Indicators

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

Handover Statistics INDICATORS > Outgoing handover > Outgoing Inter BSC

� GHOOMRQR: efficiency of the outgoing external HO preparation

� GHOOMEFR: efficiency of the outgoing external HO execution

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

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

� GHOOMCDR: rate of incoming external HO failures with drop (radio + BSS)

Inter PLMN Outgoing External HO Indicators (From B8)

An indicator is created for each counter:

� REQUESTS

� ATTEMPTS

� SUCCESS

In addition, these indicators show:

� the success rate of outgoing inter-PLMN HOs,

� the ratio of outgoing inter-PLMN HO to outgoing intra-PLMN and inter-PLMN HO.






1 � 4 � 45


External HO - Exercise

� In PAIB29.REC, extract (if available):

1) 1 incoming external HO success

2) 1 outgoing external HO success

3) 1 incoming external HO failure

4) 1 outgoing external HO failure

Time allowed:

15 minutes






1 � 4 � 46

5 Handovers QoS per Adjacency






1 � 4 � 47


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 counted

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






1 � 4 � 48


Type 180 Indicators

� From these 3 counters, the following indicators are computed:

Cell A

Cell B

Cell C

Matrix Inc allocated rate

30

10

40

Matrix Inc successMatrix Inc efficiency

rate

200Cell C - Cell B

30300Cel C - Cell A

220Cell B - Cell C

150Cell B - Cell A

1010Cell A - Cell C

80100Cell A - Cell B

Matrix Inc unsuccessrateMatrix Inc allocatedMatrix Inc requestServ - Tgt

100

150

10

300

200220

80/100 40/80 (100-40)/100100% 100% 100%

10% 100% 90%

Fill up Fill up

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






1 � 4 � 49


Type 180 Indicators [cont.]

� The following indicators can be computed from PM Type 180 counters in order to:

� Detect the most important neighboring cells as per their traffic

� Distribution of incoming handovers performed to cell T from serving cells Sn = C402(Sx,T) / ∑ C402(Sn,T)

� Ease the diagnosis of the bad handover performance of a cell

� Global Success of incoming handovers to cell T from cell S

HOOASUR = C402(S,T) / C400(S,T)

� Allocation Success of the incoming handover preparation to cell T from cell S

HOOACAR = C401(S,T) / C400(S,T)

� Efficiency of the incoming handover execution to cell T from cell S

HOOAEFR = C402(S,T) / C401(S,T)


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.






1 � 4 � 50


Type 26: TCH outgoing handover per adjacency

� Some handover indicators are available per couple of (serving, target) cells on demand for all outgoing adjacencies of a serving cell through PM type 26 (40 cells since B8)

Target a

Te

Serving

Tc

Tb

Tf

C72i(S,Te)

C72i(S,Tc)

Outgoing TCH handover for FDRC728

Outgoing TCH handover for a traffic causeC727

Outgoing TCH handover for a better cell causeC725

Outgoing TCH handover for an emergency causeC724

Outgoing TCH handover -execution radio failures without ROCC723

Outgoing TCH handover -execution radio failures with ROCC722

Outgoing TCH handover successes.C721

Outgoing TCH handover attemptsC720






1 � 4 � 51


Type 27: 2G TCH incoming handover per adjacency

� Some handover indicators are available per couple of (serving, target) cells on demand for all incoming adjacencies of a target cell through PM type 27.

Serving a

Se

Target

Sc

Sb

Sf

C73i(Se,T)

C73i(Sc,T)

Incoming 2G TCH handover with unknown or missing causesC738

Incoming 2G TCH handover for FDRC738

Incoming 2G TCH handover for a traffic causeC737

Incoming 2G TCH handover for a better cell causeC735

Incoming 2G TCH handover for an emergency causeC734

Incoming 2G TCH handover execution radio failures with or without ROC

C733

Incoming 2G TCH handover successes.C731

Incoming 2G TCH handover attemptsC730

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.






1 � 4 � 52


Type 27 Indicators

� The following indicators can be computed from PM Type 27 counters in order to ease the diagnosis of the bad incoming handover performance of a cell:

� Efficiency of the incoming handover execution to cell T from cell Sx

HOIXSUR = C731(Sx,T) / C730(Sx,T)

� Rate of incoming ho execution failures due to MS radio access problems to cell T from cell Sx

HOIXCDRR = C733(Sx,T) / C730(Sx,T)

� Rate of incoming ho execution failures due to BSS problems to cell T from cell Sx

HOIXCDBR= [C730(Sx,T)-C731(Sx,T)-C733(Sx,T)] / C730(Sx,T)


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






1 � 4 � 53

6 Inter-PLMN and Inter-RAT






1 � 4 � 54


Inter-PLMN HO Description

� Since B8, outgoing inter-PLMN HO are available (incoming were always available)

� Usage of CGI in the OMC-R allows to define outgoing inter-PLMN adjacencies (serving cell from own PLMN, target cell from foreign PLMN)

FRANCE ITALIE

OMC-R

External cells : belong to another OMC-R (from own PLMN or foreign PLMN)

Internal cells : belong to this OMC-R

Up to 4 foreign PLMN's can be defined in one OMC-R.

Inter-PLMN external cells are defined by their CGI

Outgoing

Incoming

MCC is the Mobile Country Code, MNC is the Mobile Network Code, LAC is the Location Area Code, CI is the

Cell Identification.

Handovers towards cells belonging to a different PLMN are not possible if CGI_REQD is set to 0.

Handovers towards UMTS cells belonging to a different PLMN are not possible if CGI_3G_REQUIRED is set to

0.

The MS will only measure those Neighbour cells which have a BSIC whose PLMN colour code matches with

the coding in the “NCC Permitted” transmitted to the MS in the SYSTEM INFORMATION TYPE 6.






1 � 4 � 55


Inter-PLMN Indicators

RTCH_HO_Inc_InterPLMN_request

RTCH_HO_Inc_InterPLMN_success

RTCH_HO_Inc_InterPLMN_allocated

RTCH_HO_Out_InterPLMN_request

RTCH_HO_Out_InterPLMN_attempt

RTCH_HO_Out_InterPLMN_success

RTCH_HO_Inc_InterPLMN_request_ratio

RTCH_HO_Inc_InterPLMN_request_ratio : RTCH_HO_Inc_InterPLMN_request / RTCH_HO_request






1 � 4 � 56


2G-3G Indicators

HO_Inc_MSC_3G_2G_request

HO_Inc_MSC_3G_2G_success

HO_Inc_MSC_3G_2G_allocated

HO_Inc_MSC_3G_2G_fail_radio

HO_Inc_MSC_3G_2G_HOreject_HL_Time

HO_Inc_MSC_3G_2G_TCH_fail_3GcongHO_Inc_MSC_3G_2G_TCH

request

HO_Inc_MSC_3G_2G_TCHrequest_emergency

HO_Out_MSC_2G_3G_required

HO_Out_MSC_2G_3G_request

HO_Out_MSC_2G_3G_success HO_Out_MSC_2G_3G_ROC

HO_Out_MSC_2G_3G_prep_fail

HO_Out_MSC_2G_3Gfailure_radio

HO_Inc_MSC_3G_2G_fail_BSS

HO_Inc_MSC_3G_2Gfail_prep_System

HO_Out_MSC_2G_3Gdrop_BSS

INCOMING

OUTGOING

HO_Inc_MSC_3G_2G_HOreject_HL_Time :

- Cumulative time (in seconds) during which the Cell is in 3G high load state

- i.e. Whenever the 3G_HOReject_Load State in the cell is reported as high or reported as indefinite while

the previous state was high. This counter shall be incremented only if THR_CELL_LOAD_3G_REJECT <

100%.






1 � 4 � 57







1 � 4 � 58


Handover Cause Distribution

� HO CAUSE DISTRIBUTION : distribution of HO attemps by cause X : UL/DL Qual, UL/DL Lev, UL/DL Interference, Distance, Better Cell, Interband, Micro cells HO, Concentric Cell, Traffic, AMRS, TFO causes

� Indicator aiming at measuring the efficiency of planning /optimization

GHCSTBPBR,

GHCCCELVDR,

GHCCCELVUR,

GHCCCBCPR,

GHCSTEDIR,

GHCSTEIFDR,

GHCSTELVDR,

GHCSTEQLDR,

GHCSTBDRR,

GHCMBBCPR,

GHCMCEBSR,

GHCMCELVDR,

GHCMCBCPR,

GHCMCELVUR,

GHCSTEMIR,

GHCSTEIFUR

GHCSTELVUR,

GHCSTEQLUR,

GHCSTAMR,

GHCSTBTFR

Ref. nameComments

%•Qual DL > 10%•Qual UL > 10%•Level UL > 20%•Level DL > 20%•Interf UL > 5%•Interf DL > 5%•Better Cell < 30%

(MC67w or MC785x or MC586y or MC10zz or MC447 or MC461

(MC67all + MC785all + MC586all + MC10all + MC447 + MC461)•MC67all=MC671+MC672+MC673+MC674+MC675+MC676+MC677+MC6

78+MC679+MC670•MC785all = MC785a + MC785d + MC785e + MC785f (Microcell)•MC586all = MC586a + MC586b + MC586c (concentric)•MC10all = MC1040 + MC1044 + MC1050

HO cause distribution







1 � 4 � 59


Handover Standard Cause Distribution

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

� Indicator aiming at measuring the efficiency of planning / optimization

� Interesting for comparing HO distribution after concentric or micro cell implementation

GHCSTEIFDSR,

GHCSTEIFUSR,

GHCSTEIFSR,

GHCSTELVDSR,

GHCSTELVUSR,

GHCSTELVSR,

GHCSTEQLDSR,

GHCSTEQLUSR,

GHCSTEQLSR,

GHCSTBPBSR,

GHCSTEDISR

Ref. nameComments

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

Distribution HO cause standard


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"






1 � 4 � 60


Handover Cause Distribution

�HANDOVER CAUSE rates


Handover statistics INDICATORS > Handover causes

GHCXXYYYYR: Rate of specific HO cause xxyyyy versus all HO causes (Global)

� where XX = ST (standard) or MC (micro cell) or CC (concentric cell) or MB (multi band)

� and YYYY is specific to the cause






1 � 4 � 61


Outgoing Handover Success Rate

�Global success rate of Outgoing HO : Rate of successful outgoing external and internal intercell SDCCH and TCH HO

GHOORSUR

Ref. name

This indicator includes preparation and execution.

Comments

%90%HO_Out_success/HO_Out_requiredHO_Out_success_rate

UnitThreshold

FormulaeIndicator

� Efficiency rate (also called execution success rate) of Outgoing HO : Rate of successful outgoing external and internal intercell SDCCH and TCH HO

GHOOREFR

Ref. name

This indicator

takes into account

HO execution only

(not HO

preparation).

Comments

%90%HO_Out_success/HO_Out_requestHO_Out_efficiency_rate

UnitThreshold

FormulaeIndicator

Global Outgoing HO success rate: represents the global efficiency of the outgoing handovers performed from

one cell to any of its neighboring cells (same BSS or not).

Efficiency of Outgoing HO execution: represents the efficiency of the channel change procedure during

outgoing handovers performed from one cell to any of its neighboring cells (same BSS or not). It does not take

into account the HO failures that can occur during the preparation phase when the new channel is being

selected and activated.

HO_Out_success = HO_Out_MSC_2G_3G_success + HO_Out_MSC_2G_2G_success + HO_Out_BSC_success

HO_Out_required = HO_Out_MSC_2G_2G_required+HO_Out_BSC_required+HO_Out_MSC_2G_3G_required

HO_Out_request = HO_Out_MSC_2G_2G_request+HO_Out_BSC_request+HO_Out_MSC_2G_3G_request

HO_Out_request is incremented whenever the 44.018 HANDOVER COMMAND is sent on the Abis.






1 � 4 � 62


Incoming Handover Success Rate

�Global success rate of Incoming HO : Rate of successful incoming external and internal intercell SDCCH and TCH HO

GHOIRSUR

Ref. nameComments

%90%HO_Inc_success / HO_Inc_requestHO_Inc_success_rate

UnitThreshold

FormulaeIndicator

� Success rate of execution of Incoming HO : Rate of successful incoming external and internal intercell SDCCH and TCH HO

GHOIREFR

Ref. name

Excluding

congestion failures

and BSS

preparation

failures from

requests.

Comments

%90%HO_Inc_success / HO_Inc_allocatedHO_Inc_efficiency_rate

UnitThreshold

FormulaeIndicator

Global Incoming HO success rate: represents the global efficiency of the incoming handovers performed to one

cell from any of its neighboring cells (same BSS or not).

Efficiency of Incoming HO execution: represents the efficiency of the channel change procedure during

incoming handovers performed to one cell from any of its neighboring cells (same BSS or not). It does not take

into account the HO failures that can occur during the preparation phase when the new channel is being

selected and activated.

HO_Inc_success = HO_Inc_MSC_success + HO_Inc_BSC_success

HO_Inc_request = HO_Inc_MSC_request + HO_Inc_BSC_request

HO_Inc_allocated = HO_Inc_MSC_allocated + HO_Inc_BSC_allocated






1 � 4 � 63


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

Coverage

� Coverage hole

Coverage hole may exist when coverage areas of two BTSs do not overlap or there are some big obstacles in the

coverage area, this lead to no signal or very poor signal level.

� Over shooting

In the actual network, the high BTS antenna can propagate far away along a road and serve in area which 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.






Module 5Directed Retry Indicators









EVOLIUM Base Station Subsystem � BSS B10 Introduction to Quality of Service and Traffic Load MonitoringGSM QoS Monitoring � Directed Retry Indicators

1 � 5 � 2

Blank Page




Document History






1 � 5 � 3

Module Objectives


� Describe the counters and indicators used for monitoring the efficiency of the directed retry feature






1 � 5 � 4








1 � 5 � 5

Table of Contents


1 Directed Retry Definition 7Queuing Is Mandatory 8TCH Assignment with Queuing 9Normal and Forced Directed Retry 10Directed Retry Rules 11Directed Retry During Queuing 12

2 Queuing and (F)DR Indicators 13Queuing 14Directed Retry 15Self-assessment on the Objectives 16End of Module 17






1 � 5 � 6









1 � 5 � 7

1 Directed Retry Definition






1 � 5 � 8


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.

T11 : BSC parameter, Maximum queuing time for Assignment Requests (values : 0 to 19 s; default 6s)






1 � 5 � 9


TCH Assignment with Queuing

T11TCH resource becomes "free" in the serving cell

MC13a

if the BSC has enough queuing buffers to queue the request or there is a lower priority request that can be

dequeued, BSC puts the request in a queue and starts the queuing timer T11.

Note A: This chart describes the case where the congestion situation ends as a result of a TCH being made

available on the serving BTS. Note that the congestion situation can also be handled by the Directed retry

procedure, in which case the MS is handed over to a Point-to-Point TCH

located on another BTS, see next slides.

Note B: If the queuing is not allowed by the MSC, but QUEUE_ANYWAY = TRUE, no QUEUING INDICATION

message is sent to the MSC

Note C: ATER CONN REQ procedure is done only for TDM BTS in case of BSS transport mode = IP.






1 � 5 � 10


Normal and Forced Directed Retry

� Directed Retry (DR)

� When a TCH request is in queue, the BSC tries to establish the TCH connection on a neighboring cell if:

� the normal handover condition is met (Normal DR)

� specific directed retry conditions are met (Forced DR):

� the MS receives a sufficient signal level from a neighboring cell

� the number of free TCHs in this neighboring cell is sufficient

Normal DR : Should be enabled all the time, to avoid call drop. It just allows a MS in a queue to perform a standard HO.

Forced DR : Should be enabled to fight congestion. It leads to a radio quality degradation (MS not in the best serving cell anymore).






1 � 5 � 11


Directed Retry Rules

� DR FAIL. CASES > DR Reminder

DR as an SDCCH to TCH handover can be

� Internal

� between two cells of the same BSC

� also called intra BSC

� External

� between two cells of different BSCs

� also called inter BSC

� Incoming

� as considering the target cell

� Outgoing

� as considering the serving cell

� Synchronous

� between 2 cells

� sharing the same clocks

� collocated

� usually 2 sectors of the same BTS

� tunable at OMC-R level

� Asynchronous

� not synchronous for any reason

� no 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.






1 � 5 � 12


Directed Retry During Queuing

… then, SDCCH released in the serving cell …

Detection of possible DRwith neighbour

Same message flowas a Handover

End with Assignment Complete(not "HO Performed")

MC144e/f MC153

MC717a

MC142e/f

MC144e : outgoing internal DR request

MC144f : outgoing external DR request

MC153 : incoming internal DR request (no counter for incoming external DR)

MC142e : outgoing internal DR success

MC142f : outgoing external DR success

MC717a : incoming internal DR success (no counter for incoming external DR)






1 � 5 � 13

2 Queuing and (F)DR Indicators






1 � 5 � 14


Queuing

� Alc_Mono_Queuing

RTCH queueing failure - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) - 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone: Global - Medium)

020406080

100120140160180200

16/05

/200

9 22

22:00

17/05

/200

9 00

00:00

17/05

/200

9 02

02:00

17/05

/200

9 04

04:00

17/05

/200

9 06

06:00

17/05

/200

9 08

08:00

17/05

/200

9 10

10:00

17/05

/200

9 12

12:00

17/05

/200

9 14

14:00

17/05

/200

9 16

16:00

17/05

/200

9 18

18:00

17/05

/200

9 20

20:00

nb

00.0%

20.0%

40.0%

60.0%

80.0%

100.0%

120.0%

%

Rejected

Timeout

Success

% Success

Rejected : A queued request is rejected because another request is placed in the queue, with a higher

priority.

Timeout : The queued request stayed T11 in the queue and is then removed.






1 � 5 � 15


Directed Retry

� Alc_Mono_DR_Outgoing

Outgoing internal Directed Retry - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) - 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone:

Global - Medium)

0

200

400

600

800

1000

1200

1400

16/0

5/20

09 2

2 22

:00

16/0

5/20

09 2

3 23

:00

17/0

5/20

09 0

0 00

:00

17/0

5/20

09 0

1 01

:00

17/0

5/20

09 0

2 02

:00

17/0

5/20

09 0

3 03

:00

17/0

5/20

09 0

4 04

:00

17/0

5/20

09 0

5 05

:00

17/0

5/20

09 0

6 06

:00

17/0

5/20

09 0

7 07

:00

17/0

5/20

09 0

8 08

:00

17/0

5/20

09 0

9 09

:00

17/0

5/20

09 1

0 10

:00

17/0

5/20

09 1

1 11

:00

17/0

5/20

09 1

2 12

:00

17/0

5/20

09 1

3 13

:00

17/0

5/20

09 1

4 14

:00

17/0

5/20

09 1

5 15

:00

17/0

5/20

09 1

6 16

:00

17/0

5/20

09 1

7 17

:00

17/0

5/20

09 1

8 18

:00

17/0

5/20

09 1

9 19

:00

17/0

5/20

09 2

0 20

:00

17/0

5/20

09 2

1 21

:00

nb

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%

80.00%

90.00%

%

Fail BSS

Fail Radio

ROC

Prep Fail

Success

% Success

There is also an indicator (not in this graph) that counts only the number of FDR attempts (DR_forced,

GDRFORQN = MC607)

This indicator can be compared to MC144e/f in order to know the ratio FDR vs. normal DR.






1 � 5 � 16









1 � 5 � 17

End of ModuleDirected Retry Indicators






Module 6Radio Measurement Statistics Indicators









EVOLIUM Base Station Subsystem � BSS B10 Introduction to Quality of Service and Traffic Load MonitoringGSM QoS Monitoring � Radio Measurement Statistics Indicators

1 � 6 � 2

Blank Page




Document History






1 � 6 � 3

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






1 � 6 � 4








1 � 6 � 5

Table of Contents


1 Radio Measurement Statistics Objectives 7RMS Objectives 8

2 RMS Implementation in the BSS 10RMS Management 11RMS Configuration in the OMC-R 12RMS Configuration in NPO 13RMS Data Flow 14RMS Data Presentation 15

3 RMS Data 16RMS Data Presentation 17

4 Call Quality Statistics per TRX 184.1 Generalities 194.2 Call Quality Parameters 224.3 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 RMS Indicators Usage 547.1 Suspecting a Voice Quality Problem 557.2 Suspecting a Cell Coverage Problem 56Exercise 1 58Exercise 2 59

7.3 Suspecting a Cell Interference Problem 60Exercise 3 61Exercise 4 62Exercise 5 63

8 Additional Information 64RMS Counters 65Self-assessment on the Objectives 68End of Module 69






1 � 6 � 6








1 � 6 � 7

1 Radio Measurement Statistics Objectives






1 � 6 � 8


RMS Objectives

� Assess the quality of cell coverage

� Assess the radio link quality of a TRX / a cell

� Assess Carrier/Interference ratio of a TRX / a cell

� Estimate the voice quality of a TRX / a cell

� In order to:

� Optimize the neighborhood & frequency planning

� Improve the network coverage

� Detect faulty hardware components responsible of bad QoS

� Help logical parameters fine tuning

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.






1 � 6 � 9


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.






1 � 6 � 10

2 RMS Implementation in the BSS






1 � 6 � 11


RMS Management

� RMS results are reported permanently (once a day) by the BSS as a PM Type 31 counters to the OMC-R

� The RMS job is defined and activated on a per BSS basis

� RMS job parameters are managed through RMS templates

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

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

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

Templates parameters define the intervals for Received level, Consecutive frame erasure, Radio link

counter, Path balance, C/I …for which RMS counters are provided.






1 � 6 � 12


RMS Configuration in the OMC-R

� RMS with OMC-R only

� Templates are defined on the OMC-R

� RMS results are retrieved once a day from the BSC

� Binary files can be exported for post-processing

PM

RMS in binary filesTemplatesTemplates






1 � 6 � 13


RMS Configuration in NPO

� RMS with OMC-R & NPO� Templates are defined on NPO

� RMS results are retrieved once a day from the BSC

� Binary files are transferred to NPO

� RMS warnings on NPO

� RMS QoS reports on NPO

� RMS reports used in NPO

� Check

� QoS follow-up

� Diagnosis

� Tuning

Templates

PM

A9159 NPOSoftware application

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

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






1 � 6 � 14


RMS Data Flow

1. NPO 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 NPO

5. RMS QOS report displayed

OMC-R

BSS

Template

1

PM4

2PM

3

5

QOS

NPO

The tuning function of NPO defines a preferred RMS template depending on cell characteristics (type, class,

capacity, etc.).

NPO manages the frequencies to monitor through MAFA jobs depending on the neighborhood and the

frequency bands.

NPO is a reference for RMS templates:

� 16 templates stored in the NPO database,

� Reference values for templates available,

� Extra editor in the administration tool to modify templates: a given value or a reference one.

� NPO stores RMS jobs measurements, at Cell & TRX levels (15 days).

� NPO makes some consolidations (voice quality, averages, etc.).

� NPO manages some warnings on RMS indicators (path balance).






1 � 6 � 15


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






1 � 6 � 16

3 RMS Data






1 � 6 � 17

3 RMS Data

RMS Data Presentation

� The main RMS statistics types:

� Call Quality Statistics which qualify calls according to coverage/interference criteria

� based on samples corresponding to measurement results averaged over a number of SACCH multi-frames

� Radio Quality Statistics:

� UL/DL level, UL/DL qual

� CFE

� AMR (Analyze the coded values)

� Timing Advance

� C/I Statistics on neighboring freq/MAFA freq

� last 2 statistics types based on samples corresponding to measurement results

Annex 1

The first RMS Statistics type is based on calls.

The two others are based on TRX/Cell.

Additional information: Measurement results, TRX, BS/MS max power

MAFA = Mobile Assisted Frequency Allocation is a GSM Phase 2+ feature allowing to request a mobile to measure and report through Extended Measurement Report message a C/I value for each frequency specified in an Extended Measurement Order message.

CFE: Consecutive Frame Erasure

1 SACCH multi-frame (SACCH mfr) corresponds to 4 consecutive sequences of 26 TDMA frames during which, in the uplink, a measurement report message is received by the BTS from the MS.






1 � 6 � 18

4 Call Quality Statistics per TRX






1 � 6 � 19


4.1 Generalities

� Suspecting a Voice Quality problem

� Percentage 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 NPO tool per TRX, per Cell:

� Number of Noisy calls suffering from problem of bad coverage on the uplink path

RMVQULVN = RMS_call_noisy_UL_bad_coverage

� Number of Noisy calls suffering from problem of interference on the uplink path

RMVQUIFN = RMS_call_noisy_UL_interference

� Number of Noisy calls suffering from problem of interference and bad coverage considered together on

the uplink path

RMVQUUKN = RMS_call_noisy_UL_undefined

� Rate of Noisy calls suffering from problems of interference or/and bad coverage on the uplink path

RMVQUNOR = RMS_call_noisy_UL_rate

Note: The 4 indicators above can be provided for Noisy calls suffering from VQ problems on the downlink

path.

� Rate of Noisy calls but with good FER measurements on the uplink path

RMVQFEGR = RMS_call_noisy_good_FER_rate

� Rate of Noisy calls and also with bad FER measurements on the uplink path

RMVQFEBR = RMS_call_noisy_bad_FER_rate

� Rate of calls with fair quality measurements but with bad FER measurements on the uplink path

RMVQFEAR = RMS_call_abnormal_bad_FER_rate

This last indicator can be used in order to tune the RMS VQ parameters used to characterize a call as Noisy.






1 � 6 � 20


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 mfr

VQ_AVERAGE = 4 SACCH MultiframesAV_RXLEV_UL_VQ = (RxlevUL1+RxlevUL2+RxlevUL3+RxlevUL4) / 4

AV_RXLEV_DL_VQ = (RxlevDL1+RxlevDL2+RxlevDL3+RxlevDL4) / 4

AV_RXQUAL_UL_VQ = (RxqualUL1+RxqualUL2+RxqualUL3+RxqualUL4) / 4

AV_RXQUAL_DL_VQ = (RxqualDL1+RxqualDL2+RxqualDL3+RxqualDL4) / 4

AV_RXFER_UL_VQ = (Nb of speech frames wrongly decoded (BFI=1)/ Total nb of speech frames of the CQS)

Average level, quality and FER of a Call Quality Sample

CQS: Call Quality Sample

VQ_AVERAGE = Number of consecutive SACCH measurements from which the reported Level and Quality

notes (UL and DL) are averaged. The resulting averages represent the level and quality of the corresponding

Call Quality Sample, i.e. the portion of the call over which level and quality have been measured.

Default value of VQ_AVERAGE is 6 SACCH mfr but in the example above it has been considered to be set to

4 Samfr.

AV_RXLEV_xx_VQ = Average xx level measured over a Call Quality Sample (VQ_AVERAGE SACCH)

AV_RXQUAL_xx_VQ = Average xx quality measured over a Call Quality Sample (VQ_AVERAGE SACCH)






1 � 6 � 21



� Classification of a CQS and Noisy Call identification

� How to qualify the quality of a call? By looking at the repartition of the CQS!

quality

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






1 � 6 � 22


4.2 Call Quality Parameters

� RMS parameters: Call Quality Statistics

Parameters used to determine if a call is noisy (according to RXQUAL)

and of bad voice quality (according to FER)

� VQ_AVERAGE: averaging window size on measurement results to obtain Call Quality Samples (CQSs) (0 SACCH mfr to 128 Smf)

� VQ_RXLEV: radio level threshold to specify a bad coverage CQS for noisy call statistics (-110 to -65 dBm)

� VQ_RXQUAL: radio quality threshold to specify a bad quality (RXQUAL) CQS for noisy call statistics (0 to 7)

� VQ_RXQUAL_VS_RXFER: radio quality threshold to specify a bad or a good quality CQS correlated to bad or good FER measurements for noisy call statistics (0 to 7)

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.






1 � 6 � 23


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






1 � 6 � 24


4.3 Call Quality Counters

� RMS counters

� VQ_NOISY_UL_INTERFERENCE = RMS10 Number of calls suffering from interference problem on the uplink path

� VQ_NOISY_UL_INTERFERENCE is incremented whenever a call verifies: 100*(INTERFERED_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD

� with INTERFERED_UL_SAMPLES = nb of times where AV_RXQUAL_UL_VQ > VQ_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






1 � 6 � 25


4.3 Call Quality Counters [cont.]

� RMS counters

� VQ_NOISY_UL_INTERFERENCE = RMS10Number of calls suffering from interference problem on the uplink path

� VQ_NOISY_DL_INTERFERENCE = RMS11Number of calls suffering from interference problem on the downlink path

� VQ_NOISY_UL_COVERAGE = RMS12 Number of calls suffering from bad coverage problem on the uplink path

� VQ_NOISY_DL_COVERAGE = 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_THRESHOLD

with

INTERFERED_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL

and AV_RXLEV_UL_VQ>VQ_RXLEV

considering

AV_RXQUAL_UL_VQ: average on VQ_AVERAGE measurements of RXQUAL_UL

AV_RXLEV_UL_VQ: average on VQ_AVERAGE measurements of RXLEV_UL

NUM_UL_SAMPLES: total number of averages calculated on UL measurements during the call on the considered TRX

RMS11 = VQ_NOISY_DL_INTERFERENCE is incremented whenever a call verifies: 100*(INTERFERED_DL_SAMPLES / NUM_DL_SAMPLES) > VQ_INTF_THRESHOLD

with

INTERFERED_DL_SAMPLES = nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL

and AV_RXLEV_DL_VQ>VQ_RXLEV

considering

AV_RXQUAL_DL_VQ: average on VQ_AVERAGE measurements of RXQUAL_DL

AV_RXLEV_DL_VQ: average on VQ_AVERAGE measurements of RXLEV_DL

NUM_DL_SAMPLES: total number of averages calculated on DL measurements during the call on the considered TRX

RMS12 = VQ_NOISY_UL_COVERAGE is incremented whenever a call verifies: 100*(BAD_COVERAGE_UL_SAMPLES /

NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD

with BAD_COVERAGE_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL and

AV_RXLEV_UL_VQ<=VQ_RXLEV

RMS13 = VQ_NOISY_DL_COVERAGE is incremented whenever a call verifies: 100*(BAD_COVERAGE_DL_SAMPLES /

NUM_DL_SAMPLES) > VQ_INTF_THRESHOLD

with BAD_COVERAGE_DL_SAMPLES = nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL and

AV_RXLEV_DL_VQ<=VQ_RXLEV






1 � 6 � 26



� 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_THRESHOLD

and 100*(INTERFERED_UL_SAMPLES / NUM_UL_SAMPLES) <= VQ_INTF_THRESHOLD

and 100*(BAD_QUALITY_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD

with

BAD_COVERAGE_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL and

AV_RXLEV_UL_VQ<=VQ_RXLEV

INTERFERED_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL

and AV_RXLEV_UL_VQ > VQ_RXLEV

BAD_QUALITY_UL_SAMPLES = INTERFERED_UL_SAMPLES + BAD_COVERAGE_UL_SAMPLES

= nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL

RMS15 = VQ_NOISY_DL_UNDEFINED is incremented whenever a call verifies:

100*(BAD_COVERAGE_DL_SAMPLES / NUM_DL_SAMPLES) <= VQ_INTF_THRESHOLD

and 100*(INTERFERED_DL_SAMPLES / NUM_DL_SAMPLES) <= VQ_INTF_THRESHOLD

and 100*(BAD_QUALITY_DL_SAMPLES / NUM_DL_SAMPLES) > VQ_INTF_THRESHOLD

with

BAD_COVERAGE_DL_SAMPLES = nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL

and AV_RXLEV_DL_VQ<=VQ_RXLEV

INTERFERED_DL_SAMPLES = nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL

and AV_RXLEV_DL_VQ > VQ_RXLEV

BAD_QUALITY_DL_SAMPLES = INTERFERED_DL_SAMPLES + BAD_COVERAGE_DL_SAMPLES

= nb of times when AV_RXQUAL_DL_VQ > VQ_RXQUAL






1 � 6 � 27



� 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_THRESHOLD

and 100*(BAD_QUAL_BAD_FER_UL_SAMPLES / BAD_QUALITY_UL_SAMPLES) > VQ_FER_THRESHOLD

with



BAD_QUAL_BAD_FER_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL_VS_RXFER and

AV_RXFER_UL_VQ > VQ_BAD_RXFER

considering

AV_RXFER_UL_VQ: average on VQ_AVERAGE measurements of FER

RMS17 = VQ_NOISY_UL_GOOD_FER is incremented whenever a call verifies:

100*(BAD_QUALITY_UL_SAMPLES / NUM_UL_SAMPLES) > VQ_INTF_THRESHOLD

and 100*(BAD_QUAL_GOOD_FER_UL_SAMPLES / BAD_QUALITY_UL_SAMPLES) > VQ_FER_THRESHOLD

with



BAD_QUAL_GOOD_FER_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ > VQ_RXQUAL_VS_RXFER

and AV_RXFER_UL_VQ <= VQ_GOOD_RXFER

RMS18 = VQ_ABNORMAL_BAD_FER is incremented whenever a call verifies:

100*(FAIR_QUAL_BAD_FER_UL_SAMPLES / FAIR_QUALITY_UL_SAMPLES) > VQ_FER_THRESHOLD

with

FAIR_QUALITY_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ < VQ_RXQUAL_VS_RXFER

FAIR_QUAL_BAD_FER_UL_SAMPLES = nb of times when AV_RXQUAL_UL_VQ<VQ_RXQUAL_VS_RXFER and

AV_RXFER_UL_VQ>VQ_BAD_RXFER






1 � 6 � 28

5 Radio Quality Statistics per TRX






1 � 6 � 29


5.1 Generalities

� Suspecting a TRX hardware problem

� Average path balance


� Vector of the Number of Measurement Results per Path Balance band

RMPBV = RMS_PathBalance_sample

� Average Path Balance value

RMPBAN = RMS_PathBalance_avg

A Templates modification is needed to have more details.

Report : MONO_OBJECT_DISTRIBUTION

� Alc_Mono_Radio_Link_detailed






1 � 6 � 30



� Vector Counter

� RMS7a=TPR_PATH_BALANCE RMS7b=MAX_PATH_BALANCE

� The real number of Measurement Results in which Path balance is in PATH BALANCE band j is equal to:

� S(PATH BALANCE band j) x Max / 254

� TPR_PATH_BALANCE(j) x MAX_PATH_BALANCE / 254

The vector counter system is used to provide:

� Path balance repartition

� Radio Link counter (Consecutive Frame Erasure) repartition

� C/I repartition

� AMR FR/HR/DL/UL usage repartition

� TA repartition (improved)






1 � 6 � 31



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






1 � 6 � 32


5.2 Radio Quality Parameters

� RMS Parameters

� Radio Quality Statistics: Parameters used to define intervals for RXLEV, Path Balance, Radio Link Counter and Consecutive Frame Erasure, TA 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

dBm value according to the frequency band of the TRX.

� BS_TXPWR is the BTS transmitted power offset defined relatively to the maximum absolute

output power of the BTS (negative value in dB).

� BTS_MAX_OUTPUT_POWER is the maximum power of the BTS after Combiner (in dBm).

� RXLEV_DL is the received signal levels measured by the MS on the downlink path (in dBm).

NOTE: Additional asymmetric DL loss (external combiner) or UL gain (TMA) will have an impact on the UL

and DL path loss measurements that must be taken into account when interpreting the RMS results for path

loss and path balance.






1 � 6 � 33


5.2 Radio Quality Parameters [cont.]

� RMS Parameters


� TA_STAT: threshold on the timing advance value defining a priori the range of the cell (0 to 64 bits)

� MEAS_STAT_TA1 to MEAS_STAT_ TA9: 9 thresholds for the timing advance to define 10 TA Bands

� MEAS_STAT_S1 to MEAS_STAT_S9: 9 thresholds on the BTS Radio Link Counter S value defining 10 S bands

0 < MEAS_STAT_S(i) ≤ MEAS_STAT_S(i+1) ≤ 128 SACCH mfr

� S: counter managed by the BTS on a per call basis

� S = RADIOLINK_TIMEOUT_BS if good radio conditions

� S decremented if bad radio conditions

� The BSS triggers a call drop when S = 0


� RMSpt3 = TAB_PAR_MEAS_STAT_S = Table of 9 parameters MEAS_STAT_Si

� RMSpb = PAR_TA_STAT

� RMSpt6 = TAB_PAR_MEAS_STAT_TA = Table of value for 9 parameters: MEAS_STAT_TA1 to TA9

a threshold on Timing Advance measurement to define bands used for RMS

Reminder on the Uplink Radio Link Supervision procedure:

� For each active dedicated radio channel in a cell, a counter “S” called Radio Link Counter is:

� decremented by 1 by the BTS each time an SACCH measurement from the mobile cannot be decoded

(SACCH_BFI=1).

� incremented by 2 by the BTS each time a valid SACCH measurement is received from the mobile

(SACCH_BFI=0).

� Initial value of S = RADIOLINK_TIMEOUT_BS (cell parameter)

� if S reaches N_BSTXPWR_M, a radio link recovery is triggered (BTS and MS power increased at their

maximum).

� if S reaches 0, a Radio Link Failure is triggered (channel drop).

� Therefore the value of S gives a measure of the “quality” of the radio uplink.






1 � 6 � 34


5.2 Radio Quality Parameters [cont.]

� RMS Parameters


� MEAS_STAT_BFI1 to MEAS_STAT_BFI9: 9 thresholds on the number of consecutive speech frames with BFI set to 1 defining 10 BFI bands

0 ≤ MEAS_STAT_BFI(i) ≤ MEAS_STAT_BFI(i+1) < 25 speech frame

� The BTS decodes 24 speech frames (sf) from 1 uplink SACCH multi-frame:

� and 1 SACCH frame (or block)

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

SA

C

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

SACCH mfrTDMA: 4,616ms

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

SA

C

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

SA

C

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

SA

C

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

T

C

H

Sf 1 Sf 2 Sf 3 Sf 4 Sf 5 Sf 6 Sf 7 Sf 8 Sf 9 Sf 10 Sf 11 Sf 12 Sf 13 Sf 14 Sf 15 Sf 16 Sf 17 Sf 18 Sf 19 Sf 20 Sf 21 Sf 22 Sf 23 Sf 24


RMSpt2 = TAB_PAR_MEAS_STAT_BFI = Table of 9 parameters MEAS_STAT_BFIi

Consecutive Frame Erasure (CFE)

MEAS_STAT_BFIi parameters define 9 intervals of cumulated numbers of consecutive speech frames which

have a Bad Frame Indicator value set to 1 (it means that the speech frame is considered as erroneous by

the BTS).

As the TC will erase speech frames for which a Bad Frame Indicator flag (BFI) has been set to the value 1 by

the BTS, a BFI is used in the RMS counters description whereas the CFE is used in the RMS indicators defined

in the NPO tool.

Note: By default, a BFI relates to a speech frame. When considering SACCH measurement, SACCH_BFI

should be used.






1 � 6 � 35


5.3 Radio Quality Counters

� RMS Counters

� Radio Quality Statistics

� TPR_RXQUAL_UL_RXLEV_UL: matrix of 8x10 elements UL(RXQUAL i, RXLEV band j), each element is made up of:

� Samplesij: norm of number of measurement result samples in which UL RxQual is equal to i and UL RxLev is reported in RXLEV band j

� MS PWR levelij: average value of MS power (in dBm) from pwr levels reported in these samples

� Timing Advanceij: average value of TAs reported in these samples

� TMR_RXQUAL_UL_RXLEV_UL: vector of 10 elements ULRXQUAL(RXLEV band j), each element is made up of:

� the maximum value of the 8 real numbers of samples in which UL RxQual is equal to i (i=0 to 7) and UL RxLev is reported in RXLEV band j

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






1 � 6 � 36


5.3 Radio Quality Counters [cont.]

� RMS Counters


� TPR_RXQUAL_DL_RXLEV_DL: matrix of 8x10 elements DL(RXQUAL i, RXLEV band j), each element is made up of:

� Samplesij: norm of number of measurement result samples in which DL RxQual is equal to i and DL RxLev is reported in RXLEV band j

� BS PWR levelij: average value of BS power (in dBm) from pwr levels reported in these samples

� Timing Advanceij: average value of TAs reported in these samples

� TMR_RXQUAL_DL_RXLEV_DL: vector of 10 elements DLRXQUAL(RXLEV band j), each element is made up of:

� the maximum value of the 8 real numbers of samples in which DL RxQual is equal to i (i=0 to 7) and DL RxLev is reported in RXLEV band j

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






1 � 6 � 37



� RMS Counters


� TPR_PATH_BALANCE: vector of 10 elements UL/DL(PATH BALANCE band j), each element is made up of:

� the norm of number of measurement result samples for which the computed Path Balance is in PATH BALANCE band j

� MAX_PATH_BALANCE:

� the maximum value of the 10 real numbers of samples for which the computed Path Balance is in PATH BALANCE band j (j=1 to 10)

RMS7a=TPR_PATH_BALANCE RMS7b=MAX_PATH_BALANCE

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






1 � 6 � 38



� RMS Counters


� TPR_RADIO_LINK: vector of 10 elements UL(S band j), each element is made up of:

� the norm of number of measurement result samples for which the Uplink Radio Link Counter is in S band j

� MAX_RADIO_LINK:

� the maximum value of the 10 real numbers of samples for which the Uplink Radio Link Counter is in S band j (j=1 to 10)

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






1 � 6 � 39



� RMS Counters


� TPR_BFI_RXLEV_UL: matrix of 10x10 elements UL(BFI i, RXLEV band j), each element is made up of:

� the norm of number of SACCH multi-frames in which the number of consecutive speech frames with BFIs set to 1 is in BFI band i and UL RxLev reported in the corresponding measurement results is in RXLEV band j

� TMR_BFI_RXLEV_UL: vector of 10 elements ULBFI(RXLEV band j), each element is made up of:

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

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






1 � 6 � 40



� RMS Counters


� The BTS increments the BFI (or CFE) counter as soon as consecutive speech frames cannot be decoded

� isolated speech frames with BFIs set to 1 are not counted

� sequences of not decoded speech frames are cumulated

SACCH mfr

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

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






1 � 6 � 41



� RMS Counters for AMR Monitoring


� To provide a better tool to dimension the AMR thresholds, B9 introduces a new set of RMS counters to verify the use of different speech codecs: For Full Rate and Uplink:

� AMR_FR_UL_BAD= RMS44a that has 8 cells (1 for each FR codec) with the relative number of bad speech frames received in uplink.

� MAX_AMR_FR_UL_BAD= RMS44b that indicates the maximum number of bad speech frames received in uplink in one FR codec.

� AMR FR codec used in uplink (TRX based)






1 � 6 � 42





� AMR thresholds; different speech codecs: For Half Rate and Uplink:

� AMR_HR_UL_BAD= RMS45a that has 8 cells (1 for each HR codec) with the relative number of bad speech frames received in uplink.

� MAX_AMR_HR_UL_BAD= RMS45b that indicates the maximum number of bad speech frames received in uplink in one HR codec.

� AMR HR codec used in uplink (TRX based)






1 � 6 � 43





AMR Table; different speech codecs: For Full Rate, UL & DL

� AMR_FR_UL_RXLEV_UL= RMS46a that has a table (8x10) with relative number of correct speech frames received in uplink in each AMR FR codec (8 codecs) and each level band (10 level bands).

� MAX_AMR_FR_UL_RXLEV_UL= RMS46b that has the 10 maximum results. Each cell Ci of the table indicates the greatest value of the Vik for a i given in RMS46a.

� AMR_FR_DL_RXLEV_DL= RMS47a that has a table (8x10) with relative number of correct speech frames received in downlink in each AMR FR codec (8 codecs) and each level band (10 level bands).

� MAX_AMR_FR_DL_RXLEV_DL= RMS47b that has a table of 10 maximum results. Each cell Ci of the table indicates the greatest value of the Vik for a i given in RMS47a.

AMR-FR codec usage compared to RXLEV

RXLEV UL bands are defined as follows:






1 � 6 � 44





AMR Table; different speech codecs: For Half Rate, UL & DL

� AMR_HR_UL_RXLEV_UL= RMS48a that has a table (5x10) with relative number of correct speech frames received in uplink in each AMR HR codec (5 codecs) and each level band (10 level bands).

� MAX_AMR_HR_UL_RXLEV_UL= RMS48b that has a table of 10 maximum results. Each cell Ci of the table indicates the greatest value of the Vik for a i given in RMS48a.

� AMR_HR_DL_RXLEV_DL= RMS49a that has a table (5x10) with relative number of correct speech frames received in downlink in each AMR HR codec (5 codecs) and each level band (10 level bands).

� MAX_AMR_HR_DL_RXLEV_DL= RMS49b that has a table of 10 maximum results. Each cell Ci of the table indicates the greatest value of the Vik for a i given in RMS49a.

AMR-HR codec usage compared to RXLEV

RXLEV UL bands are defined as follows:






1 � 6 � 45



� RMS Counters for Timing Advance


� PERC_TA_GT_TA_STAT:

� percentage of measurement results reported with a Timing Advance value > TA_STAT parameter

� MAX_TA:

� maximum value of Timing Advance among all TA values reported in the measurement results used for RMS

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.



1 � 6 � 46




� A new set of RMS counters related with timing advance analysis.TRX Based. (Rxlev for UL and DL)

� TPR_TIMING_ADVANCE= RMS50a that has 10 cells (1 for each timing advance band) with relative number of measurements in each Timing advance band.

� MAX_TIMING_ADVANCE = RMS50b that has the greatest number of measurements in one Timing advance band.

� TPR_UL_RXLEV_TA_BAND= RMS51 that has 10 cells (1 for each timing advance band) with average of uplink rxlev in corresponding timing advance band.

� TPR_DL_RXLEV_TA_BAND= RMS52 that has 10 cells (1 for each timing advance band) with average of downlink rxlev in corresponding timing advance band.




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



1 � 6 � 47




� A new set of RMS counters related with timing advance analysis.

Uplink :

� TPR_UL_RXQUAL_TA_BAND = RMS53 : Vector of 10 cells containing the average UL RxQual measured for each TA band (1 cell per TA band)

Downlink :

� TPR_DL_RXQUAL_TA_BAND = RMS54 : Vector of 10 cells containing the average DL RxQual measured for each TA band (1 cell per TA band)




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



1 � 6 � 48




� MAX_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






1 � 6 � 49

6 C/I Statistics






1 � 6 � 50

6 C/I Statistics

6.1 C/I Generalities

� Storage and Computation Methods

� In order to provide an efficient storage, the "vector method" already seen for previous RMS statistics will be used for C/I counters

� C/I expressed in logarithmic scale (dB)

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






1 � 6 � 51

6 C/I Statistics

6.2 C/I Parameters

� RMS Parameters

� C/I statistics: parameters defining intervals for C/I statistics

� MEAS_STAT_C_I1 to MEAS_STAT_C_I9: 9 thresholds on the Carrier/Interference ratio defining 10 C/I bands

-63 < MEAS_STAT_C_I(i) ≤ MEAS_STAT_C_I(i+1) ≤ +63 dB

� EN_BALANCED_CI: boolean indicating if the C/I value reported by the BTS is balanced or not

� NEIGB_CELL_ID: (BCCH,BSIC) of the neighboring cell for which the C/I statistics per neighboring cell are reported

� Frequency ARFCN: ARFCN of the frequency for which the C/I statistics per MAFA frequency are reported

Annex 2


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






1 � 6 � 52

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






1 � 6 � 53

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






1 � 6 � 54

7 RMS Indicators Usage






1 � 6 � 55


7.1 Suspecting a Voice Quality Problem

� Percentage of Noisy calls

� FER is more reliable than RXQUAL to assess VQ

� Noisy calls indicators can also be computed from FER measurements

� Noisy calls with bad or good FER

� Calls not detected as noisy but with bad FER

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 path

RMVQULVN = RMS_call_noisy_UL_bad_coverage

� Number of Noisy calls suffering from problem of interference on the uplink path

RMVQUIFN = RMS_call_noisy_UL_interference

� Number of Noisy calls suffering from problem of interference and bad coverage considered together on

the uplink path

RMVQUUKN = RMS_call_noisy_UL_undefined

� Rate of Noisy calls suffering from problems of interference or/and bad coverage on the uplink path

RMVQUNOR = RMS_call_noisy_UL_rate

Note: The 4 indicators above can be provided for Noisy calls suffering of VQ problems on the dowlink path.

� Rate of Noisy calls but with good FER measurements on the uplink path

RMVQFEGR = RMS_call_noisy_good_FER_rate

� Rate of Noisy calls and also with bad FER measurements on the uplink path

RMVQFEBR = RMS_call_noisy_bad_FER_rate

� Rate of calls with fair quality measurements but with bad FER measurements on the uplink path

RMVQFEAR = RMS_call_abnormal_bad_FER_rate

This last indicator can be used in order to tune the RMS VQ parameters used to characterize a call as Noisy.






1 � 6 � 56


7.2 Suspecting a Cell Coverage Problem

� Distribution of samples per RxQual value and RxLev band

� Distribution of samples per RxLev band

Not acceptable

coverage 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 band

RMQLDSAM = RMS_DL_RxQuality_RxLevel_sample

� Vector of Percentage of Samples per DL RxLev band

RMQLDLVDV = RMS_DL_RxLevel_distrib

� Vector of Percentage of Samples per DL RxQual band

RMQLDQUDV = RMS_DL_RxQuality_distrib






1 � 6 � 57


7.2 Suspecting a Cell Coverage Problem [cont.]

� Average TA values per RxQual value and RxLev band

Not acceptable

coverage limit:

Too low level

Too bad quality

Acceptable coverage limit:

Sufficient level and good quality

% of TA value over TA

threshold has also to be

considered

In order to know if the coverage problem is due to a big amount of traffic at the cell border or rather to

indoor calls, the average TA value per RXQUAL value and RXLEV band as well as the Percentage of TA

values over the TA threshold should be observed.

� Matrix of Average TA per UL RxQual value and per UL RxLev band

RMQLUTAM = RMS_UL_RxQuality_RxLevel_TimingAdvance

� Rate of Measurements Results whose TA is greater than the TA threshold

RMTAGTR = RMS_TimingAdvance_greater_threshold_rate

� Maximum TA value of all values reported in Measurement Results

RMTAMXN = RMS_TimingAdvance_max






1 � 6 � 58


Exercise 1

� Give the list of the RMS counters and parameters used in the 3 previous slides.

Time allowed:

10 minutes






1 � 6 � 59


Exercise 2

� Interpret this graph.

Time allowed:

10 minutes






1 � 6 � 60


7.3 Suspecting a Cell Interference Problem

� Number of samples per RxQual value and RxLev band

Average DL RxQuality = 0.34

RMS results show no 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 band

RMQLDSAM = RMS_DL_RxQuality_RxLevel_sample

� Vector of Average DL RxQual per RxLev band

RMQLDQUAV = RMS_DL_RxQuality_avg_per_RxLevel

� Average DL RxQuality

RMQLDQUAN = RMS_DL_RxQuality_avg






1 � 6 � 61


Exercise 3


Average RxQual value per

RxLev band has also to be

considered

Average DL RxQuality =

2.81






1 � 6 � 62


Exercise 4


Time allowed:

15 minutes






1 � 6 � 63


Exercise 5

�Interpret this graph.

Time allowed:

10 minutes

Rapport NPO :

Alc_Mono_Carrier_over_interference






1 � 6 � 64

8 Additional Information






1 � 6 � 65


RMS Counters

� Counters used for post-processing the RMS results provided per TRX

� TOT_SEIZ_TCH: number of TCH channels successfully seized by the MS

� TOT_MEAS: number of Measurement Results used for RMS

� TOT_MEAS_L1INFO_NOL3INFO: number of Measurement Results used for RMS statistics for which Layer 1 info is present but Layer 3 is missing

� TOT_MEAS_DTX_UL: number of Measurement Results used for RMS statistics for which DTX UL was used in the corresponding SACCH mfr

� TOT_MEAS_DTX_DL: number of Measurement Results used for RMS statistics for which DTX DL was used in the corresponding SACCH mfr

� TOT_EMR: number of Extended Measurement Results used for RMS statistics


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






1 � 6 � 66


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 campaign

� IND_RMS_RESTARTED: boolean indicating if the RMS job has been restarted on the concerned TRE during the RMS campaign due to a modification of the RMS parameter values or a TRE reset

Corresponding RMS counter numbers: RMS20 = TRE_BAND

� RMSpw1 = BS_TX_PWRMAX

� RMSpw2 = MS_TX_PWRMAX

� RMS21 = IND_TRE_OVERLOAD

� RMS22 = IND_RMS_RESTARTED






1 � 6 � 67


RMS Counters [cont.]

� Counters used for interpreting the C/I RMS results provided per TRX:

� IND_CI_PARTIAL_OBSERVATION: made up of 2 booleans indicating that:

� C/In computation has been restarted due to the modification of the list of neighboring cells during the RMS campaign

� C/If computation has been restarted due to the modification of the list of MAFA frequencies during the RMS campaign

� IND_CI_OVERFLOW: boolean indicating that the upper limit of 42 C/I sets of counters has been exceeded (each new reported neighboring cell (BCCH, BSIC) has not been taken into account in RMS statistics)


� RMS23 = IND_CI_PARTIAL_OBSERVATION

� RMS24 = IND_CI_OVERFLOW






1 � 6 � 68









1 � 6 � 69

End of ModuleRadio Measurement Statistics Indicators






Module 7Traffic Indicators3JK11049AAAAWBZZA Issue 01








EVOLIUM Base Station Subsystem � BSS B10 Introduction to Quality of Service and Traffic Load MonitoringGSM QoS Monitoring � Traffic Indicators

1 � 7 � 2

Blank Page




Document History






1 � 7 � 3

Module Objectives


� Describe BSS traffic indicators used for radio resource dimensioning






1 � 7 � 4








1 � 7 � 5

Table of Contents


1 Call Mix Definition 7GSM Transactions 8Example 10Variation 11Usage 12Advises 13Exercise 14

2 Basis of Traffic Theory 15Erlang Definition 16Erlang from Call Mix 17Erlang B Law 18Erlang B Formulae 20Erlang B Abacus 21Erlang B Example 22Non Linearity of Erlang B 23Cell Dimensioning 24Dimensioning "a Priori" 25Dimensioning "a Posteriori" 26Forecast / Critical Traffic 27Exercise 28

3 TCH Resource Allocation Indicators 29Radio Allocation and Management 30MS Access 31Speech Coding Version 32Distributions 33

4 Resource Occupancy Indicators 34TCH Resource 35TCH Resource 36SDCCH / ACH Resource 37

5 Traffic Model Indicators 38SDCCH Establishment Cause 39Mobiles Penetration 41SDCCH traffic indicators 43TCH traffic indicators 44

6 Preemption Indicators 45Preemption Principle 46Preemption Counters 47Preemption Feature 48Self-assessment on the Objectives 49End of Module 50






1 � 7 � 6









1 � 7 � 7

1 Call Mix Definition






1 � 7 � 8


GSM Transactions

� In a GSM Network, there are a lot of different transactions:

� location update: periodic, new updating, ~imsi_attach, ~imsi_detach

� Hand Over (intra-cell, internal, external, etc.)

� SMS (Short Message Service, originating or terminating)

� SS (Supplementary Service) (i.e: number presentation)

� Paging

� and also Originating and Terminating calls, etc.

� and so on (data, SMS-CB, etc.)

In a GSM network, telecom procedures involve different kind of resources in the BSS:

� Location Update: RACH, AGCH, SDCCH and SCCP

� Originated Call: RACH, AGCH, SDCCH, TCH and SCCP

� Terminated Call: PCH, RACH, AGCH, SDCCH, TCH and SCCP

� Handover: TCH, SCCP

� etc.






1 � 7 � 9


GSM Transactions [cont.]

� One can quantify the number of each transaction per hour

� For example, for one cell, one can measure:

� 900 calls (600 TCs, 300 OCs)

� 3600 LUs (any type)

� 1350 HOs (900 internal, 450 external)

� 100 SMSs

� 5 SSs

� 6000 pagings

� With the following characteristics

� mean call duration on TCH: 50 seconds

� mean SDCCH duration: 3.2 seconds

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.






1 � 7 � 10


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

� HO/Call : 1.5 (2/3 internal, 1/3 external)

� SMS/Call : 11 %

� SS/call : 5 %

� Paging/hour : 6000

� mean call duration on TCH : 90 seconds

� mean SDCCH duration : 4.2 seconds

After commercial opening, the number of calls per hour will be measured from traffic counters.

Usually the Marketing team will provide:

� on a per geographical area or morphostructure basis:

� the traffic per km2 (in Erlang),

� the traffic per subscriber (in mErl).

� the number of calls per hour.






1 � 7 � 11


Variation

� A call mix is varying a lot:

� from a cell to another

� TCH traffic (induced by subscribers)

� number of LU/call and HO/call (induced by network design)

� from one hour to another

� by default: busy hour

� from one year to another

� modification of traffic intensity and distribution

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






1 � 7 � 12


Usage

� Interests of call mix: Input data for dimensioning

� Cell and BSC resources dimensioning

� RTCH, SDCCH, TTCH, BTS, BSC and MSC CPU processor

� Some examples of "risky" call mix

� too many LU/Calls: SDCCH congestion, TCU load, MSC overload

� too many HO/calls: speech quality, call drop, DTC load

� too many calls: TCH congestion

� too many paging: DTC processor load, PCH congestion

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.






1 � 7 � 13


Advises

� Some advises

� LU/CALL: 1 is "good", 2 is "bad", 4 and more can be dangerous

� beware of the Network or BSC averages which can hide critical cells

� HO/Call: less critical (1 is good)

� 2 or 3 is not a direct problem, but the trend has to be monitored

� Call: to be checked with an Erlang table (seen in next session)






1 � 7 � 14


Exercise

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

� 256 calls/hour

� 1300 LUs/hour

� 450 HOs/hour

� Is it complete?

� What are the risks of such a call mix?

Time allowed:

15 minutes






1 � 7 � 15

2 Basis of Traffic Theory






1 � 7 � 16


Erlang Definition

� ERLANG: unit used to quantify traffic (intensity)

T = (resource usage duration) / (total observation duration) [ERLANG]

� Example:

� For 1 TCH, observed during 1 hour

� one can observe 2 calls: 1 of 80 seconds and 1 of 100 seconds

T = (80+100)/3600 = 0.05 ERLANG






1 � 7 � 17


Erlang from Call Mix

� Call mix example:

� 350 calls/hour

� 3 LUs/call

� TCH mean call duration: 85 seconds

� SDCCH mean duration: 4.5 seconds

� Computation of Carried Erlang

TCH = (350*85)/3600: 8.26 ERLANGS

SDCCH = [ (350+350*3) * 4.5 ] / 3600 = 1.75 Erlang






1 � 7 � 18


Erlang B Law

� In a Telecom system, the call arrival frequency is ruled by the POISSON law

� Erlang B law: relationship between:

� offered traffic

� number of resources

� blocking rate






1 � 7 � 19


Erlang B Law [cont.]

� The call request arrival rate (and leaving) is not stable

number of resources = average number of requests * mean duration

is sometimes not sufficient => probability of blocking

=> Erlang B law

� Pblock: blocking probability

� N: number of resources

� E: offered traffic [Erlang]

� Good approximation when the blocking rateis low (< 5 %)

Telecom system

OfferedCarried

Rejected

Pblock (Blocking probablity) : Probability that a resource request may be rejected by the system due to

insufficient resource availability at the moment of the request.

The Erlang B law is not fully accurate since it assumes that:

� the subscriber requests are not queued which is not always the case (TCH queued in the BSC),

� the subscriber does not repeat his call request if rejected, which is almost never the case.

Therefore the higher the blocking rate the worse is the approximation of the Erlang B law.

The Erlang C law modelizes better the TCH resource usage of the BSS since it takes into account the queuing.

However the Erlang C law is never used since parameters like size of the queue and time spent into the queue have to be tuned.






1 � 7 � 20


Erlang B Formulae

� There are two different ways to use this law

� Using Abacus

� Using SW (here Excel)

� Pblock = f (T, Nc)

� Offered = f (Nc, Pblock)

� Channels = f (T, Pblock)






1 � 7 � 21


Erlang B Abacus






1 � 7 � 22


Erlang B Example

� Example:

1 cell with 8 TRXs, with 60 TCH channels

Maximum blocking rate: 2 %

� Erlang law: 50 Offered Erlang

� 83 % of TCH resources used to reach 2% of blocking






1 � 7 � 23


Non Linearity of Erlang B

� But be careful, the Erlang B law is not linear:

� If we use for example a combined BCCH with a micro BTS.

� 4 SDCCHs, Pblock = 2% => T = 1.1 E

� 25% resources used to reach 2% blocking

� if we decide to provide SMSCB (Cell Broadcast information), 1 SDCCH stolen for CBCH

� 3 SDCCHs, Pblock = 2% => T = 0.6 E

� 25% resources less => 50% Traffic less!!






1 � 7 � 24


Cell Dimensioning

� Given an Offered traffic, compute the number of TRXs (and SDCCH) needed to carry it => What is the accepted blocking rate?

� Default blocking rate

� RTCH: 2 %

� SDCCH: 0.5 %

� (for BSC TTCH: 0.1%)

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.






1 � 7 � 25


Dimensioning "a Priori"

� Cell dimensioning from call mix (bid, architecture)

� to handle an offered traffic of 12 Erlangs (RTCH), compute the number of channels, then the number of TRXs

Channels (12;2%) = 19

example: 3 TRXs, 21 TCHs, 1 BCCH, 2 SDCCHs/8






1 � 7 � 26


Dimensioning "a Posteriori"

� Cell dimensioning from measurement (re-planning)

� one is measuring a traffic of 15 Erlangs, with a blocking rate of 10%

� how to dimension the cell?

Offered traffic = 15 / (1-10%) = 16.7 Erlangs!!!!

Channels (16.7;2%) -> 25 TCHs -> 4 TRXs needed






1 � 7 � 27


Forecast / Critical Traffic

� Forecast traffic

� traffic forecasting must be computed according to the offered traffic

� not directly on the measured traffic

� In order to plan the necessary actions soon enough, one must compute regularly the date when the traffic of a cell will become critical

� Critical traffic

� critical traffic: when the offered traffic will induce 2% of blocking

� traffic capacity of a cell = critical traffic of this cell






1 � 7 � 28


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






1 � 7 � 29

3 TCH Resource Allocation Indicators






1 � 7 � 30


Radio Allocation and Management

� Radio resource allocation and management (RAM) aims at:

� Managing pools of TCH radio resources by:

� defining TCH radio timeslots as a function of the cell radio configuration from the operator

� sorting these TCH TSs according to their radio capabilities (FR or DR, frequency band(G1 or GSM/DCS))

� Allocating dedicated TCH radio resources by:

� selecting the TCH pool in which the TCH should be chosen according to:� the requested channel rate (FR or HR)

� the radio capability of the mobile

� the TRE DR capability and the TRE band

� selecting the best TCH resource among the available TCH channels of this pool according to several criteria






1 � 7 � 31


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






1 � 7 � 32


Speech Coding Version

� Speech coding Version capabilities distribution (NA only)Accessibility in type 110 since B8

� TCH allocations with FR SV1TCNACAFN= MC702A

� TCH allocations with HR SV1 TCNACAHN= MC702B

� TCH allocations with FR SV2 (EFR) TCNACAEN= MC702C

� TCH allocations with FR SV3 (AMR FR) TCNA3CAFN= MC704A

� TCH allocations with HR SV3 (AMR HR) TCNA3CAHN= MC704B

� TCH allocations for data call TCNACADN= MC705


Traffic Load and Traffic Model > TCH traffic > Speech version and Channel type

These indicators can only be computed if PM Type 1 is activated in B7. From B8, the counters needed for

these Indicators are added to type 110.

The following indicators are also computed:

� Ratio of TCH allocations with FR SV1 over all TCH allocations during normal assignment

= TCNACAFTO = MC702A / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)

� Ratio of TCH allocations with HR SV1 over all TCH allocations during normal assignment

= TCNACAHTO = MC702B / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)

� Ratio of TCH allocations with EFR over all TCH allocations during normal assignment

= TCNACAETO = MC702C / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)

� Ratio of TCH allocations with AMR FR over all TCH allocations during normal assignment

= TCNA3CAFTO = MC704A / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)

� Ratio of TCH allocations with AMR HR over all TCH allocations during normal assignment

= TCNA3CAHTO = MC704A / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)

� Ratio of TCH allocations for Data calls over all TCH allocations during normal assignment

= TCNACADTO = MC705 / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)

� Rate of successful TCH allocations with AMR SV over all AMR MS requests

= TCNA3SUR = (MC704A+MC704B) / MC701D






1 � 7 � 33


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 TRX

� Number of TCH allocations for Normal AssignmentTCNACAN = MC703


Traffic Load and Traffic Model > TCH traffic > Resource occupancy

� MC370A = Number of FR TCH allocations (FR+EFR+AMR FR)

� MC370B = Number of HR TCH allocations (HR+AMR HR)

� MC703 = Number of TCH allocations for Normal Assignment

� MC15A = Number of TCH allocations for Internal Directed Retry

� MC15B = Number of TCH allocations for Handover (intra cell, internal, external)

TCNACAN indicator is also available as the MAX value of the day on the NPO tool.

Some of these indicators are also available for SDCCH:

� SDCCH allocation distribution per TRX through the number of SDCCH allocations

SDAHCAN = MC390

� SDCCH Assignment/HO distribution through the ratio of SDCCH allocations for Assignment

SDNACAO = MC148 / MC390






1 � 7 � 34

4 Resource Occupancy Indicators






1 � 7 � 35


TCH Resource

� TCH resource occupancy

� TCH traffic in ErlangTCTRE= (MC380A+MC380B) / 3600

� TCH mean holding time (TCH average duration)TCTRMHT= (MC380A+MC380B) / (MC370A+MC370B)

� FR TCH traffic in ErlangTCTRE= MC380A / 3600

� FR TCH mean holding timeTCTRFMHT= MC380A/ MC370A

� HR TCH traffic in ErlangTCTRE= MC380B / 3600

� HR TCH mean holding timeTCTRHMHT= 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 TRX

A split of counters (MC380a and MC380b) is added, in B8, to make the distinction between traffic in different

frequency bands: here after the corresponding stored indicators (type 110):

� TCTRFTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the

GSM frequency band is busy in FR usage = MC380C

� TCTRHTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the

GSM frequency band is busy in HR usage = MC380D

� TCTRFTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the

DCS/PCS frequency band is busy in FR usage = MC380E

� TCTRHTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the

DCS/PCS frequency band is busy in HR usage = MC380F






1 � 7 � 36


TCH Resource

� Alc_Mono_RTCH_Traffic_Model

Alc_Half_rate_erlang - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) - 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone: Global - Medium)

0

5

10

15

20

25

30

35

16/05

/200

9 22

22:

00

16/05

/2009

23

23:0

0

17/05

/200

9 00

00:

00

17/0

5/20

09 0

1 01

:00

17/05

/200

9 02

02:0

0

17/0

5/20

09 0

3 03

:00

17/0

5/200

9 04

04:

00

17/0

5/20

09 0

5 05:

00

17/0

5/200

9 06

06:

00

17/0

5/200

9 07

07:

00

17/05

/200

9 08

08:

00

17/0

5/200

9 09

09:

00

17/05

/200

9 10

10:0

0

17/05

/200

9 11

11:

00

17/05

/2009

12

12:0

0

17/05

/200

9 13

13:

00

17/0

5/20

09 1

4 14

:00

17/05

/200

9 15

15:0

0

17/0

5/20

09 1

6 16

:00

17/0

5/200

9 17

17:

00

17/0

5/20

09 1

8 18:

00

17/0

5/200

9 19

19:

00

17/0

5/200

9 20

20:

00

17/05

/200

9 21

21:

00

Er

0

5

10

15

20

25

30

35

Er

half Erl total

full Erl total

RTCH Erl total

TCH resource occupancy

� TCH traffic in Erlang

TCTRE= (MC380A+MC380B) / 3600

� TCH mean holding time (TCH average duration)

TCTRMHT= (MC380A+MC380B) / (MC370A+MC370B)

� FR TCH traffic in Erlang

TCTRE= MC380A / 3600

� FR TCH mean holding time

TCTRFMHT= MC380A/ MC370A

� HR TCH traffic in Erlang

TCTRE= MC380B / 3600

� HR TCH mean holding time

TCTRHMHT= MC380B/ MC370B

TCTRFTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the GSM

frequency band is busy in FR usage = MC380C

� TCTRHTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the

GSM frequency band is busy in HR usage = MC380D

� TCTRFTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the

DCS/PCS frequency band is busy in FR usage = MC380E

� TCTRHTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the

DCS/PCS frequency band is busy in HR usage = MC380F






1 � 7 � 37


SDCCH / ACH Resource

� SDCCH resource occupancy

� SDCCH traffic in ErlangSDTRE= MC400 / 3600

� SDCCH mean holding time (SDCCH average duration)SDTRMHT= MC400 / MC390

� ACH resource occupancy

� ACH traffic in ErlangC750 / 3600

� ACH mean holding time (ACH average duration) QSTRN =C750 / C751


Traffic Load and Traffic Model > SDCCH traffic > Resource occupancy

� MC400 = Cumulated SDCCH duration per TRX

� MC380 = Number of SDCCH allocations per TRX

C750 and C751 are 2 counters introduced from B7 in type 18. Both are provided per TTCH (A channel):

� C750 = TIME_A_CHANNEL_BUSY: Time (in seconds) during which the A channel is busy (allocated)

� C751 = NB_A_CHANNEL_ALLOC: Number of allocations of the A channel






1 � 7 � 38

5 Traffic Model Indicators






1 � 7 � 39


SDCCH Establishment Cause

� Alc_Mono_SDCCH_Traffic_Model

MS originated traffic split - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) - 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone: Global - Medium)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

16/0

5/2009

22

22:0

0

17/05

/200

9 00

00:00

17/0

5/200

9 02

02:

00

17/0

5/20

09 0

4 04:0

0

17/0

5/200

9 06

06:

00

17/0

5/20

09 0

8 08:

00

17/05

/200

9 10

10:0

0

17/0

5/20

09 1

2 12:

00

17/05

/200

9 14

14:0

0

17/0

5/20

09 1

6 16:

00

17/05

/200

9 18

18:0

0

17/0

5/20

09 2

0 20:

00

nb

LCS

Other

IMSI detach

Suppl Service

SMS

LU FOR

Location Update

MOC






1 � 7 � 40


SDCCH Establishment Cause [cont.]

� SDCCH establishment cause distribution

� Ratio of MT callsTMMTO= MC01 / SDCCH ASSIGN SUCCESS

� Ratio of MO normal and emergency callsTMMTO= MC02H / SDCCH ASSIGN SUCCESS

� Ratio of LU normal (resp. follow-on)TMMOLUR = MC02A (resp. MC02D) / SDCCH ASSIGN SUCCESS

� Ratio of IMSI detachTMMOLUDR= MC02G / SDCCH ASSIGN SUCCESS

� Ratio of Short Message ServiceTMMOSMSR= MC02B / SDCCH ASSIGN SUCCESS

� Ratio of Supplementary ServiceTMMOSSR= MC02C / SDCCH ASSIGN SUCCESS

� Ratio of Call re-establishmentTMMOCRR= MC02E / SDCCH ASSIGN SUCCESS


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.






1 � 7 � 41


Mobiles Penetration

� Alc_Mono_SpeechVersion_and_ChannelType_detailed

Split of requests - CELL2G: cell00301_03017 (301/3017) ( 999/F77/301/3017 ) - 17/05/2009 00 00:00 To 17/05/2009 23 23:00 (Working Zone: Global - Medium)

0%

20%

40%

60%

80%

100%

16/05

/200

9 22

22:00

17/05

/200

9 00

00:00

17/05

/200

9 02

02:00

17/05

/200

9 04

04:00

17/05

/200

9 06

06:00

17/05

/200

9 08

08:00

17/05

/200

9 10

10:00

17/05

/200

9 12

12:00

17/05

/200

9 14

14:00

17/05

/200

9 16

16:00

17/05

/200

9 18

18:00

17/05

/200

9 20

20:00

nb

Data

AMR

DR_EFR

DR

FR






1 � 7 � 42


Mobiles Penetration [cont.]

� E-GSM mobiles penetration

� Ratio of E-GSM MS access over all MS accesses (except LU)TMMSEGR = MC706 / ([MC01+MC02]-[MC02A+MC02D+MC02G])

� Multiband mobiles penetration

� Ratio of Multiband MS access over all MS accesses (except LU)TMMSMBR = MC850 / ([MC01+MC02]-[MC02A+MC02D+MC02G])

� AMR mobiles penetration

� Ratio of TCH allocation for AMR MS over all TCH allocationsTCTR3CATTO = MC704A+ MC704B / MC703

� TFO calls ratio

� Ratio of successful TFO establishment over all TCH allocationsQSTRCCTR = MC170 / MC703

� Handover per Call

� Number of Handovers (intra cell, internal, external) per Normal AssignmentTMHOCO = (MC717A+MC717B) / MC718


� Traffic Load and Traffic Model > SDCCH traffic > MS penetration rate

� Traffic Load and Traffic Model > TCH traffic > Speech version and Channel type

� [MC01+MC02]-[MC02A+MC02D+MC02G] = Total number of initial accesses for call establishment (except

location update)

� MC706 = Number of initial accesses for call establishment (except location update) of MS supporting the 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






1 � 7 � 43


SDCCH traffic indicators

Report :

Alc_Mono_SDCCH_traffic






1 � 7 � 44


TCH traffic indicators

Report :

Alc_Mono_RTCH_traffic






1 � 7 � 45

6 Preemption Indicators






1 � 7 � 46


Preemption Principle

� Preemption attributes (in Assignment or HO Request):

� pci: preemption capability indicationindicates if the call can preempt another call (pci=1) or not

� pvi: preemption vulnerability indicationindicates if the call is preemptable (pvi=1) or not

� priority level: 1=highest priority / 14=lowest priority

� Preemption rules:

� A TCH request with pci=1 and priority level=p1 will preempt an on-going call with pvi=1 and priority level=p2, p2 lower than p1 (whatever 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.






1 � 7 � 47


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 calls

� MC921D = Number of preemption capable TCH Request (pci=1) successfully served in a neighboring cell with the help of the directed retry procedure

� MC921E = Number of preemptable calls successfully established (pvi=1)


GLOBAL Quality of service INDICATORS> RTCH > Preemption feature






1 � 7 � 48


Preemption Feature

� Preemption capable TCH Request rejection rate

� TCPPFLCR = (MC921A-MC921B-MC921D) / MC921A

� Ratio of preemption capable TCH Request which led to a successful Directed Retry

� TCPPDSUCR = MC921D / MC921A

� Ratio of preemptable calls established over all calls

� TCPPSUVO = MC921E / (MC718+MC717A+MC717B)


GLOBAL Quality of service INDICATORS> RTCH > Preemption feature






1 � 7 � 49









1 � 7 � 50

End of ModuleTraffic Indicators






Module 8Case Studies









EVOLIUM Base Station Subsystem � BSS B10 Introduction to Quality of Service and Traffic Load MonitoringGSM QoS Monitoring � Case Studies

1 � 8 � 2

Blank Page




Document History






1 � 8 � 3

Module Objectives


� Analyze with the KPI QoS some typical problems






1 � 8 � 4








1 � 8 � 5

Table of Contents


1 Congestion 7Congestion Analysis 8

2 Sector Problem 9Scetor Problem Analysis 10

3 QSCSSR 11QSCSSR Analysis 12

4 Quality 13Quality Analysis 14

5 RMS Level 15RMS Level Analysis 16

6 Interference 17Interference Analysis 18

7 BSS Problem 19BSS Problem Analysis 20Self-assessment on the Objectives 21End of Module 22






1 � 8 � 6









1 � 8 � 7

1 Congestion






1 � 8 � 8

1 Congestion

Congestion Analysis

� From this NPO table: What is the worst SDCCH congested cell?

� Choose 2 other interesting indicators to continue your analysis:

� Call Drop %

� SDCCH Assignment Failure %

� Outgoing Handover Success %

� SDCCH Drop %

� Downlink TBF drop %

� RTCH assign fail %






1 � 8 � 9

2 Sector Problem






1 � 8 � 10

2 Sector Problem

Scetor Problem Analysis

� In this trisectorised site,give the worst sector.

� What can you propose to do?






1 � 8 � 11

3 QSCSSR






1 � 8 � 12

3 QSCSSR

QSCSSR Analysis

� Write the formula using the reference name (MCx) and compute the CSSR for these 2 cells:

(1 - SDCCH_drop_%) * ( 1 - RTCH_assign_unsuccess_%)

With:

� SDCCH_drop_% = SDCCH_drop / SDCCH_assign_success

� RTCH_ass_Un_%= RTCH_assign_unsuccess / RTCH_assign_request

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






1 � 8 � 13

4 Quality






1 � 8 � 14

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






1 � 8 � 15

5 RMS Level






1 � 8 � 16

5 RMS Level

RMS Level Analysis

� Find the 2 worst cells in the table. Try to propose a solution!






1 � 8 � 17

6 Interference






1 � 8 � 18

6 Interference

Interference Analysis

� Find 1 bad cell with some HO problem.

� What can you propose to do?






1 � 8 � 19

7 BSS Problem






1 � 8 � 20

7 BSS Problem

BSS Problem Analysis

� What is the worst cell?

� Propose some probable solutions.






1 � 8 � 21









1 � 8 � 22

End of ModuleCase Studies



3JK11051AAAAWBZ Issue 01



Module 9Annexes









EVOLIUM Base Station Subsystem � BSS B10 Introduction to Quality of Service and Traffic Load MonitoringGSM QoS Monitoring � Annexes

1 � 9 � 2

Blank Page




Document History






1 � 9 � 3

Module Objectives


� Describe …

� List …

� Explain …

� Identify ...






1 � 9 � 4








1 � 9 � 5

Table of Contents


1 Radio Measurement Reporting 7Radio Measurement Mechanisms 8Measurement Result Message 10

2 Extended Measurement Reporting (MAFA) 11Definition 12Extended Measurement Reporting Mechanisms 13

3 Directed Retry Indicators 14Internal DR - Success Case 15Incoming Internal DR - Failures 16Incoming Internal DR - Congestion 17Incoming Internal DR - Radio Failure 18Incoming Internal DR - Counters 19Incoming Internal DR - Indicators 20Outgoing Internal DR - Failures 21Outgoing Internal DR - Radio Failure ROC 22Outgoing Internal DR - Radio Failure Drop 23Outgoing Internal DR - Counters 24Outgoing Internal DR - Indicators 25External DR - Success 26Outgoing External DR - Failures 27Outgoing External DR - Radio Failure ROC 28Outgoing External DR - Radio Failure Drop 29Outgoing External DR - Counters 30Outgoing External DR - Indicators 31

4 GSM BSS Protocol Stacks 32Signaling Links 33The Reference Model 34BSS Protocol Stacks 37Signaling on the A Interface 39GSM BSS Protocols 40

5 LCS 42LCS Function 43LCS Function: Architecture 44Example 45LCS Counters 46LCS Counters 47Definitions 48LCS Architecture 49LCS Positioning Procedure 50LCS Protocol 51Positioning Methods: CI+TA Positioning 53Positioning Methods: Conventional GPS 54Positioning Method: Assisted GPS Positioning 55LCS Impact on HO 58BSS Parameters 61Cell Parameters 62Exercise 63Positioning Methods: CI+TA Positioning 64

6 Counters on Electromagnetic Emission (EME) 65Characteristics of the Feature 66

7 B8 Improvements 69Summary 70

8 B9 Improvements 71Summary 72

9 Dynamic SDCCH Allocation 73






1 � 9 � 6



Purpose 74Principle 75TIMESLOT Types 77Allocation Algorithm 78SDCCH Sub-Channel Selection 79Deallocation Algorithm 80O&M Configuration 81

10 Handover Detection for Concentric Cells 83Algorithms 84Handover Algorithm Cause 10 85Handover Algorithm Cause 11 86Handover Algorithms Cause 13 87Outgoing Intercell Handovers from Concentric Cell 93Incoming Intercell Handovers towards Concentric Cell 94Self-assessment on the Objectives 96End of Module 97






1 � 9 � 7

1 Radio Measurement Reporting






1 � 9 � 8


Radio Measurement Mechanisms

� MS connected (TCH or SDCCH)

� The serving cell gives to the MS the list of the neighboring cells to listen

� Every SACCH, the MS reports to the serving cell: measurement report message

� Received level of 6 best cells (which can change)

� DL level and quality of serving cell

Meast

Report






1 � 9 � 9


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






1 � 9 � 10


Measurement Result Message

L1 Info

L3 Info

Measurement

Report

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






1 � 9 � 11

2 Extended Measurement Reporting (MAFA)






1 � 9 � 12


Definition

� The Extended Measurement Reporting is a feature allowing the BSS to request an MS to measure and report up to 21 frequencies of the band that are not included in its BA list

� Such phase 2+ mobiles must support the optional Mobile Assisted Frequency Allocation (MAFA) feature






1 � 9 � 13

MS BTS BSC MSCTCH ASSIGNMENT PHASE (OC or TC)

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

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

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

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

� EMO sent once to the MS on SACCH after TCH seizure

� Extended Measurement Results include the average signal level measured on each MAFA frequency over one SACCH mf duration

� EMR received once per call on SACCH

Back

When the BTS receives a CHANNEL ACTIVATION with the Extended Measurement Order (EMO) included, it

shall send this information on the SACCH to the corresponding mobile only once.

When the BTS has to send this information, it shall replace the sending of system information 5, 5bis, 5ter

or 6 by this information. At the next SACCH multi-frame, the BTS shall resume the sending of this system

information by the replaced one.

The EMO shall be sent after 2 complete sets of SYS_INFO5 and 6, i.e. after the 2nd SYSINFO 6 after the

reception of SABM. This guarantees the MS has received a complete set.

Then, the BTS normally receives from the MS an EXTENDED MEASUREMENT RESULT with the level of the

frequencies to monitor. The BTS shall make the correlation between these levels and the frequencies

contained in the latest EMO information, after having decoded them, according to the order of the

ARFCN. The ‘EXTENDED_MEASUREMENT_RESULT’ is NOT forwarded to the BSC, instead a

‘MEASUREMENT_RESULT’ with indication ‘no_MS_results’ is sent to the BSC.

In particular, the BTS shall identify the level of the BCCH frequency of the serving cell (which shall always

be part of the frequencies to monitor) and apply it as the RXLEV_DL in the Radio Measurement Statistics.

The other frequencies will be considered in the same way as BCCH frequency of neighboring cells: they

will be linked to the neighboring level and C/I statistics.






1 � 9 � 14

3 Directed Retry Indicators






1 � 9 � 15


Internal DR - Success Case

� DR FAIL. CASES > internal DR > success case

� The same internal DR procedure leads to an incrementation of two sets of counters:

� incoming DR counters for the target cell: MC153, MC151, etc.

� outgoing DR counters for the serving cell: MC144E, MC142E, etc.

� MCx counters belong to Standard Type 110 reported permanently

� Cx counters belong to Detailed Type 29 reported on demand

� Standard type from B8

MS serving cell target cell BSC MSC

TCH ASSIGNMENT PHASE (OC or TC)< -----------------------

ASSIGNMENTREQUEST

No free TCHTCH request queued

Queuing 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 110

� for the target cell:

� MC13A: TCH requests for Normal Assignment that are put into the queue,

� MC153: incoming internal DR requests,

� MC15A: TCH allocations for incoming internal DR,

� MC151: incoming internal DR successes per cell,

� MC717A: incoming internal DR successes per TRX.

� for the serving cell:

� MC144E: outgoing internal DR requests,

� MC142E: outgoing internal DR successes,

� MC607: outgoing internal+external DR attempts.

The following DR counters are provided in Type 29 (this type becomes a standard type in B8)

� for the target cell:

� C153: incoming internal DR requests,

� C154: incoming internal DR attempts,

� C151: incoming internal DR successes.

� for the serving cell:

� C144A: forced outgoing internal DR requests,

� C144C: normal outgoing internal DR requests,

� C145A: forced outgoing internal DR attempts,

� C145C: normal outgoing internal DR attempts,

� C142A: forced outgoing internal DR successes,

� C142C: normal outgoing internal DR successes.

All the counters here and in the next slides concerning directed retry and relative to type 29 can be activated for all cells of the BSC at once from B8. (Type 29 becomes a standard type in B8): C142a, C142b, C142c, C142d, C143a, C143b, C143c, C143d, C143e, C143f, C143g, C143h, C144a, C144b, C144c, C144d, C145a, C145b, C145c, C145d, C151, C152,C153, C154, C555






1 � 9 � 16


Incoming Internal DR - Failures

� DR FAIL. CASES > Incoming internal DR failures:

� Directed Retry procedure from the target cell point of view

� DR Preparation:

� congestion: no RTCH available in the target cell� � does not concern the outgoing side (serving cell point of view)


� DR Execution:

� radio problem: the MS fails to access the new channel� � the reversion/drop discrimination concerns only the serving cell







1 � 9 � 17


Incoming Internal DR - Congestion

� DR FAIL. CASES > Incoming internal DR fail: congestion

MC555=C155

Standard Type


TCH ASSIGNMENT PHASE (OC or TC)< ----------------------------------------------------

ASSIGNMENT REQUESTNo 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.






1 � 9 � 18


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


HO CMD HANDOVER COMMAND

<----------------------- <------------------------------------------------------------------------ start T3103HANDOVER ACCESS C154

------------------------------------------------------------->-------------------------------------------------------------> HO DETECTION

PHYSICAL INFORMATION ---------------------------------->

<------------------------------------------------------------- start T3105SABM

-------------------------------------------------------------> ESTABLISH INDICATION

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

HANDOVER COMPLETE

----------------------------------------------------- - - - -XSABM

-----------------------> ESTABLISH INDICATION

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

HO FAILURE HANDOVER FAILURE

-----------------------> ------------------------------------------------------------------------> C152Release of new channel

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.






1 � 9 � 19


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






1 � 9 � 21


Outgoing Internal DR - Failures

� DR FAIL. CASES > Outgoing internal DR failures

� Directed Retry procedure from the serving cell point of view

� DR Preparation:

� congestion on the target cell (no specific counter on the serving cell)


� DR Execution:









1 � 9 � 22


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


SABM-------------------------------------------------------------> ESTABLISH INDICATION

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

HANDOVER COMPLETE----------------------------------------------------- - - - -X

SABM-----------------------> ESTABLISH INDICATION

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

HO FAILURE HANDOVER FAILURE-----------------------> ------------------------------------------------------------------------> C143A or C143E







1 � 9 � 23


Outgoing Internal DR - Radio Failure Drop

� DR FAIL. CASES > Outgoing internal DR fail: drop

C144A,C143B:

Forced DR

C144C,C143F:

Normal DR



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.






1 � 9 � 24


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






1 � 9 � 26


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 ta rget_ce ll 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 -->

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

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

< ---- 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 HOs in the related counters.






1 � 9 � 27


Outgoing External DR - Failures

� DR FAIL. CASES > Outgoing external DR failures

� Directed Retry procedure from the serving cell point of view

� DR Preparation:

� congestion on the target cell (no specific counter on the serving cell)


� DR Execution:









1 � 9 � 28


Outgoing External DR - Radio Failure ROC

� DR FAIL. CASES > Outgoing external DR fail: reversion old channel

C145B,C143C: Forced DR

C145D,C143G: Normal DR

MS serving_cell BSC MSC BSC ta rge t_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






1 � 9 � 29


Outgoing External DR - Radio Failure Drop

� DR FAIL. CASES > Outgoing external DR fail: drop

C145B,C143D: Forced DR

C145D,C143H: Normal DR

MS serving_cell BSC MSC BSC ta rge t_ce ll 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







1 � 9 � 30


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.






1 � 9 � 32

4 GSM BSS Protocol Stacks






1 � 9 � 33


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






1 � 9 � 34


The Reference Model

7 Application

6 Presentation

4 Transport

5 Session

2 Data Link

3 Network

1 Physical

User of Transport Service

Transport ServiceNetwork

Service






1 � 9 � 35


The Reference Model [cont.]

� Layer 1

� Physical; Responsible for the transparent transmission of information across the physical medium (HDB3, PCM, AMI)

� Layer 2

� Data Link; Responsible for providing a reliable transfer between the terminal and the network (#7, LAPD,etc.)

� Layer 3

� Network; responsible for setting up and maintaining the connection across a network (CM, MM, RR, Message routing, etc.)






1 � 9 � 36


The Reference Model [cont.]

� Layer 4

� Transport; responsible for the control of quality of service (Layer of information)

� Layer 5

� Session; Handles the coordination between the user processes (Set up transfer of information)

� Layer 6

� Presentation; responsible for ensuring that the information is presented to the eventual user in a meaningful way (Type format. Ex. ASCII)

� Layer 7

� Application; provides lower levels with user interface (Operating System)






1 � 9 � 37


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

MTPLAYER 2

LAYER 1

LAYER 3






1 � 9 � 38


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/s

or PCM TS64 kbit/s

or PCM TSPCM TS PCM TS

PhycalLayer

PhycalLayer






1 � 9 � 39


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






1 � 9 � 40


GSM BSS Protocols

� BSSMAP

� Contains the messages, which are exchanged between the BSC and the MSC and which are evaluated from the BSC

� In fact all the messages which are exchanged as RR (Radio Resource Management Services between the MSC, BSC and MS). Also control Information concerning the MSC and BSC

� Example: Paging, HND_CMD, Reset

� DTAP

� Messages which are exchanged between an NSS and an MS transparent. In this case, the BSC transfers the messages without evaluation transparent. Mainly Messages from Mobility Management (MM) and Call Control (CC)






1 � 9 � 41


GSM BSS Protocols [cont.]

� Relationship between DTAP, CC, MM, BSSMAP, RR

MSBSS MSC

Call Control (CC) DTAP

Radio Resource (RR)BSSMAP

Back






1 � 9 � 42

5 LCS






1 � 9 � 43

5 LCS

LCS Function

LCS function (linked to MC02i) and other counters …

� LCS allows to access the MS location provided by the BSS.

� On MS request to know its own location (MC02 impacted, see the previous slide)

� On network request (especially during Emergency calls)

� On external request (LCS Client)

� Positioning methods provided can be:

� Cell-ID or Cell-ID + TA (Timing Advance)

� Conventional (standalone) GPS

� Assisted GPS (with the help of A-GPS server to compute location)

� MS based (MB): MS is able to perform a pre-computation

� MS assisted (MA): MS sends info, Network computes

Assisted GPS Method:

� Mobile-based: The MS performs OTD signal measurements and computes its own location estimate. In this case the network provides the MS with the additional information such as BTS coordinates and the RTD

values. These assistance data can be either broadcast on the CBCH (using SMSCB function) or provided by

the BSS in a point to point connection (either spontaneously or on request from the MS).

� Mobile-assisted: The MS performs and reports OTD signal measurements to the network and the network computes the MS location estimate.

� With

� OTD: Observed Time Difference: the time interval that is observed by an MS between the receptions of signals (bursts) from two different BTSs.

� RTD: Real Time Difference: This means the relative synchronization difference in the network between two BTSs.

Finally, 4 methods are possible for positioning:

� Cell ID+ TA

� Conventional (MS equipped with GPS System)

� A-GPS MS Based

� A-GPS MS Assisted

These 4 Methods induce a set of counters (2 per method) to give the average latitude and longitude of

mobiles in the cell.

These counters are located in the MFS and can be used in RNO (cartographic part).






1 � 9 � 44

5 LCS

LCS Function: Architecture

SMLCBTS

BTS

MS

BSC

MSC

HLR

GMLC

OSP

Lg

Lh

External

LCS clientLe

AAbis

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 Center GMLC: 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.






1 � 9 � 45

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 TA

positioning method.

P804: NB_LOC_CONV_GPS_SUCC Number of successful location responses sent to the BSC using

Conventional GPS positioning method.

P805: NB_LOC_MA_AGPS_SUCC Number of successful location responses sent to the BSC using 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 Function

� POSITION AVERAGE USED ON RNO: Values are given in minutes

� LATITUDES AND LONGITUDES:

P822: AV_TA_LAT Average of latitudes for TA Method

P823: AV_TA_LONG Average of longitudes for TA Method

P824: AV_CONV_GPS_LAT Average of latitudes for Conventional GPS Method

P825: AV_CONV_GPS_LONG Average of latitudes for Conventional GPS Method

P826: AV_MA_AGPS_LAT Average of latitudes for MS-Assisted A-GPS Method

P827: AV_MA_AGPS_LONG Average of longitudes for MS-Assisted A-GPS Method

P828: AV_MB_AGPS_LAT Average of latitudes for MS-Assisted A-GPS Method

P829: AV_MB_AGPS_LONG Average of longitudes for MS-Based A-GPS Method

� STANDARD DEVIATION: standard deviation is a measure of the dispersion around the average point

P830: ST_DEV_TA_LAT Standard deviation of the latitude of MS obtained with TA

Method

P831: ST_DEV_TA_LONG Standard deviation of the longitude of MS obtained with TA

Method

P832: ST_DEV_CONV_GPS_LAT Standard deviation of the latitude of MS obtained with

Conventional GPS Method

P833: ST_DEV_CONV_GPS_LONG Standard deviation of the longitude of MS obtained with

Conventional GPS Method

P834: ST_DEV_MA_AGPS_LAT Standard deviation of the latitude of MS obtained with MS

Assisted A-GPS Method

P835: ST_DEV_MA_AGPS_LONG Standard deviation of the longitude of MS obtained with MS


P836: ST_DEV_MB_AGPS_LAT Standard deviation of the latitude of MS obtained with MS


P837: ST_DEV_MB_AGPS_LONG Standard deviation of the longitude of MS obtained with MS







1 � 9 � 48

5 LCS

Definitions

� New end-user services which provide the geographical location of an MS:

� On MS request to know its own location

� On network request (especially during Emergency calls)

� On external request (LCS Client)

� Several positioning methods:

� Cell-ID or Cell-ID + TA (Timing Advance)

� Conventional (standalone) GPS

� Assisted GPS (with A-GPS server help to compute location)

� MS-based (MB): the MS is able to perform a pre-computation

� MS-assisted (MA): the MS sends info, Network computes

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.

� With

� OTD: Observed Time Difference: the time interval that is observed by an MS between the receptions of signals (bursts) from two different BTSs.

� RTD: Real Time Difference: This means the relative synchronization difference in the network between two BTSs.

Finally, 4 methods are possible for positioning:

� Cell ID+ TA,

This is the simplest method for determining the location of a mobile. It relies on the hypothesis that the

geographical coverage of a cell corresponds to that predicted by radio coverage studies. When an active

mobile is connected to a base station, the mobile is assumed to be located geographically within the area

predicted to be best served by this base station

� Conventional (MS equipped with GPS System),

� MS-based Assisted GPS,

� MS-Assisted GPS.






1 � 9 � 49

5 LCS

LCS Architecture

MS Request1

Network Request2

External 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






1 � 9 � 50

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.






1 � 9 � 51

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






1 � 9 � 52

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_abort to supervise the SMLC response.

� Abort by BSS

The BSC must send either a PERFORM LOCATION ABORT message or a ABORT message to the SMLC and starts the timer

T_Loc_abort if an ongoing location request is interrupted at the BSC level for the following reasons:

� by an inter-BSC handover, or

� if the main signaling link to the target MS is lost or released, or

� the SCCP connection on the A interface is released, or

� if the timer T_Location expires.

The useful B8 content of the received PERFORM LOCATION REQUEST message is:

� Location type,

� Classmark information 3,

� Requested QoS: provides service requirement concerning geographic positioning and response time

� accuracy, the response time category (Low Delay or Delay Tolerant),

� Current Cell Id + TA information are always provided to the SMLC.

The time of transfer of the assitance data on the SDCCH is estimated about 14s for a 1000 octets information.






1 � 9 � 53

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_W

IDTH

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






1 � 9 � 54

5 LCS

Positioning Methods: Conventional GPS

� Conventional GPS location procedure

� This optional location procedure is chosen by the SMLC (if the MS supports it) upon reception of a Perform Location Request message from the BSC

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






1 � 9 � 55

5 LCS

Positioning Method: Assisted GPS Positioning

� Assisted GPS Positioning Method (A-GPS)

� Assistance GPS Positioning Method is split into:

� MS Based A-GPS method

� MS Assisted A-GPS method

- 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






1 � 9 � 56

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.






1 � 9 � 57

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.






1 � 9 � 58

5 LCS

LCS Impact on HO

� HO preparation

� Inhibition of “better cell handovers”

� Other HO


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.






1 � 9 � 59

5 LCS

LCS Impact on HO [cont.]

� HO management

� Internal HO


HOcomplete



LCS client

BSSLAP - Reset

Intra BSCHO

on going

BSSMAP perform location response (cause = "Intra-BSC Handover Complete)

Mobile in communication






1 � 9 � 60

5 LCS

LCS Impact on HO [cont.]

� HO management

� External HO

MS BTS Serving BSC SMLC MSC GMLC HLR

ExternalBSC HO

BSSAP-LE Perform_Location_Abort

LCS client


BSSMAP HO required







1 � 9 � 61

5 LCS

BSS Parameters

Timers

T_Location

T_Location_longer

T_Loc_Abort

T_LCS_delay_tolerant

T_LCS_LowDelay

T_RRLP_low_delay

T_RRLP_delay_tolerant

FLAGS

EN_LCS

EN_SAGI

OPTIMIZATION DATA

ARC_SIZE_FACTOR

MIN_RADIUS_FACTOR

MAX_RADIUS_FACTOR

BSS PARAMETERS

� EN_LCS (BSC): Flag which enables or disables the LCS feature in the BSS.

� EN_SAGI: Flag indicating whether SAGI is configured or not for this BSS.

� T_Location: BSC timer on a per call basis to guard the response from the SMLC in case of Location Request, when no RRLP exchange is triggered with the MS.

� T_Location_longer: BSC timer on a per call basis to guard the response from the SMLC in case of Location Request, when an RRLP exchange is triggered with the MS. Replace T_Location timer in case of Conventional GPS, MS-Assisted A-GPS, MS-Based A-GPS.

� T_Loc_Abort: BSC timer to guard the response from the SMLC in case of Location Abort.

� T_LCS_LowDelay: SMLC timer to guard the calculation of the MS position (including the RRLP message exchange with the target MS) in case of a Low Delay Location Request.

� T_LCS_DelayTolerant: SMLC timer to guard the calculation of the MS position (including the RRLP message exchange with the target MS) in case of a Delay Tolerant Location Request.

� T_LCS_LowDelay: SMLC timer to guard the calculation of the MS position (including the RRLP message exchange with the target MS) in case of a Low Delay Location Request.

� T_RRLP_Low_delay: Timer to guard the RRLP exchange between the SMLC and the MS .

� T_RRLP_delay_tolerant: Timer to guard the RRLP exchange between the SMLC and the MS.

Optimization data:


� 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






1 � 9 � 62

5 LCS

Cell Parameters

SITE DATA

LCS_LATITUDE

LCS_LONGITUDE

LCS_SIGNIFICANT_GC

LCS_AZIMUTH

HALF_POWER_BANDWIDTH

EN_CONV_GPS

EN_MS_ASSISTED_AGPS

EN_MS_BASED_AGPS

FLAGS

CELL PARAMETERS

� EN_CONV_GPS: Flag to enable/disable the Conventional GPS positioning method.

� EN_MS_ASSISTED_AGPS: Flag to enable/disable the MS Assisted A-GPS positioning method.

� EN_MS_BASED_AGPS: Flag to enable/disable the MS Based A-GPS positioning method.

� LCS_LATITUDE: Latitude of the BTS supporting the cell (used by the MFS to compute location estimate

based on TA positioning method).

� LCS_LONGITUDE: Longitude of the BTS supporting the cell (used by the MFS to compute location estimate

based on TA positioning method).

� LCS_SIGNIFICANT_GC: Indicates whether latitude and longitude are significant or not

� LCS_AZIMUTH: Antenna direction orientation for the sector supporting the cell (used by the MFS to

compute location estimate based on TA positioning method).

� HALF_POWER_BANDWIDTH: Half power beam width of the antenna for the sector supporting the cell (used

by the MFS to compute location estimate based on TA positioning method).

Remark: To have LCS supported for a cell, the operator must activate LCS on the BSS handling this cell but

he must also activate GPRS for this cell (i.e. setting of MAX_PDCH to a value > 0, the cell being kept locked

for GPRS if the operator does not want to have GPRS running on this cell) and configure all the required

transmission resources (Ater and Gb resources) on the GPU(s) connected to this BSC.






1 � 9 � 63

5 LCS

Exercise

� Where is implemented the SMLC function?

� What are the LCS impacts on cell dimensioning?

Time allowed:

10 minutes






1 � 9 � 64

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 azimuths

� r1= inner radius ofTA ring-(B-0.5)*554 in [m]

� R2=(B+C)*554 in [m]

� A: ARC_SIZE_FACTOR

� B: MIN_RADIUS_FACTOR

� C: MAX_RADIUS_FACTOR

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:


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






1 � 9 � 65

6 Counters on Electromagnetic Emission (EME)






1 � 9 � 66


Characteristics of the Feature

� The goal of this feature is to make easier evaluating power issues in BTSs

� Recording of power emission of BTS per cell and frequency band

� Triggering of warning reports based on threshold fixed by the operator to get the real emission of antennas (at BTS antenna output port)

� Take care of Environmental regulations

BSC

BTS

OMC-R






1 � 9 � 67


Characteristics of the Feature [cont.]

� GSM antennas are widely in living and working places

� Lack of information provided to people on their exposure to EM fields and the risks they are running

� People concerned about their health, risk of complaints

� Some European directives/recommendations are already applicable or will be very soon






1 � 9 � 68

6 Counters on Electromagnetic Emission (EME)Characteristics of the Feature [cont.]

� 2 new counters (Hourly from NPA for RNO reports)

� EME_PWR_GSM (850/900) (Short Name: E01)

� EME_PWR_DCS (1800/1900) (Short Name: E02)

� Power with 0.1 Watt steps

� Performance Measurement type

� New Type: Type 33

� Permanent type (PMC) with a fixed accumulation period: 1 hour

� Counters available in MPM and NPA

Back

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






1 � 9 � 69

7 B8 Improvements






1 � 9 � 70

7 B8 Improvements

Summary

� Location Services (LCS)

� SDCCH Dynamic allocation

� Counters Improvement

� Inter PLMN HO

� 3G to 2G HO (and 2G to 2G only)

� Dual band HO (New type: 32)

� LapD congestion counter

� QOS Follow-up� TCH assignment failure BSS PB now detailed

� HO Attempts for Fast Traffic added in type 110

� AMR counters added in type 110

� MS penetration (per speech version and channel type) was type 1 counters now available in type 110

� HO Causes: type 26 extended from 1 to 40 cells

� Directed retry: type 29 becomes a standard (for PMC)






1 � 9 � 71

8 B9 Improvements






1 � 9 � 72

8 B9 Improvements

Summary

� Type 31: New RMS counters

� For AMR monitoring

� For Timing Advance analysis

� For BTS Power level

� Type 33: Power at the BTS for Electromagnetic Environment Monitoring (EME) (Annex 6)

� Type 110: more counters for UMTS to GSM handover monitoring

� The new counters were introduced in MC922 family

� 2 New counters for HO Cause 30: PS return to CS Zone






1 � 9 � 73

9 Dynamic SDCCH Allocation






1 � 9 � 74


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.






1 � 9 � 75


Principle

� Principles

� Too few SDCCH time slots could result in high blocking rate on SDCCH (Configuration 1)

� Too many SDCCH time slots could lead to a lack of TCH resources (Configuration 2)

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)






1 � 9 � 76


Principle [cont.]

� Allocation and de-allocation of Dynamic SDCCH/8 time slots

� An additional dynamic SDCCH/8 timeslot is allocated by the BSC if there is no SDCCH sub-channel free in the cell.

� A dynamic SDCCH/8 timeslot is de-allocated by the BSC after T_DYN_SDCCH_HOLD (10s) delay if all of its SDCCH sub-channels become free

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.






1 � 9 � 77


TIMESLOT Types

� NEW TIMESLOT TYPES

� SDCCH

Pure SDCCH or “ static SDCCH “

� TCH

Pure TCH

� TCH/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.






1 � 9 � 78


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






1 � 9 � 79


SDCCH Sub-Channel Selection

� Pure SDCCH Timeslot

� TS with LOWEST TCU LOAD

� TS with MAXIMUM FREE SDCCH Sub channels

� TS with lowest index on TRX with lowest TRX_ID

� TCH/SDCCH TS allocated as SDCCH

� TS on FR TRX


� TCH/SDCCH TS allocated as TCH

� TS with LOWEST TCU LOAD

� TS on FR TRX


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.






1 � 9 � 80


Deallocation Algorithm

� GENERAL CASE:

� all SDCCH sub-channels of a TCH/SDCCH timeslot become back free.

� the T_DYN_SDCCH_HOLD timer (10s, not tunable) is started.

� If the timeslot is still free of SDCCH sub-channel when the timer expires, it is de-allocated (it becomes back TCH).

� SPECIAL CASE:

� several TCH/SDCCH timeslots are allocated as SDCCH

� one of them becomes free of SDCCH sub-channels. Its timer starts.

� a subsequent one becomes free of SDCCH sub-channels too before expiration of the first 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.






1 � 9 � 81


O&M Configuration

� Massive modification by script

� 10 templates

� Template customization

� Template 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

cannot have the characteristic of being a PDCH (it cannot carry GPRS traffic).

� The operator must configure at least one static SDCCH/8 or SDCCH/4 timeslot on BCCH TRX in a

cell.

� In cells with E-GSM, only the TRX, which does not belong to the G1 band, can support dynamic and

static SDCCHs.

� In multiband and concentric cells, only the TRX, which belongs to the outer zone, can support

dynamic and static SDCCHs.

� Up to 24 static/dynamic SDCCH sub-channels can be configured per TRX.






1 � 9 � 82


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?

1

2

2

34

5

6

7

8

9

10

1112

13

14

15

16

4

4

8

88

8

8

16

16

16

16

1616

16

24

24

24

8

8

16

1624

24

24

24

24

32

32

3240

40

40

48

48

12

12

24

2432

32

32

40

40

48

48

4856

56

64

72

72

12.0 (note 1)

6.0

12.0

8.08.0

6.4

5.3

5.7

5.0

5.3

4.8

4.44.7

4.3

4.6

4.8

4.5

Yes

Yes

No

NoNo

No

No

No

No

No

No

NoNo

No

No

No

No

Note1: For one TRX, dynamic SDCCHs are over-dimensioned because of the granularity of 8. According to the Alcatel-Lucent traffic model, all dynamic SDCCHs will not be used.

Note2: An additional dynamic SDCCH/8 must be provided for each DR TRX (these are expected mainly

on small cells).

Rules

At least one static SDCCH/4 or SDCCH/8 on BCCH TRX:

� Up to 24 static/dynamic SDCCH sub-channels per TRX.

� Up to 32 static/dynamic SDCCH sub-channels per TCU.

� Up to 88 static/dynamic SDCCH sub-channels per CELL.






1 � 9 � 83

10 Handover Detection for Concentric Cells






1 � 9 � 84

� Emergency handovers specific to concentric cells

� Intracell handovers from inner to outer zone

� cause 10: too low level on the uplink in inner zone

� cause 11: too low level on the downlink in inner zone

� May be triggered

� From inner zone of a concentric cell

� Towards outer zone, same cell


Algorithms

Conce

ntric cell

In n e r z o n e

Outer zone






1 � 9 � 85

� CAUSE 10: too low level on the uplink in the inner zone

AV_RXLEV_UL_HO < RXLEV_UL_ZONE

and MS_TXPWR = min (P, MS_TXPWR_MAX_INNER)

� Averaging window: A_LEV_HO


Handover Algorithm Cause 10






1 � 9 � 86

� CAUSE 11: too low level on the downlink in the inner zone

AV_RXLEV_DL_HO < RXLEV_DL_ZONE

and BS_TXPWR = BS_TXPWR_MAX_INNER

� Averaging window: A_LEV_HO


Handover Algorithm Cause 11






1 � 9 � 87

� CAUSE 13: too high level on UL and DL in the outer zone

� Better condition intracell handover

� If the cell is a multi-band cell, cause 13 is checked only for multi-band MSs

� May be triggered

� From outer zone of a concentric cell

� Towards inner zone, same cell


Handover Algorithms Cause 13

Conce

ntric cellIn n e r z o n e

Outer zone






1 � 9 � 88

� 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.]






1 � 9 � 89

� ZONE_HO_HYST_UL

� UL static hysteresis for interzone HO from outer to inner

� In case of multi-band cell, should take into account the difference of propagation between GSM and DCS

� Added to cause 10 threshold RXLEV_UL_ZONE

� ZONE_HO_HYST_DL

� DL static hysteresis for interzone HO from outer to inner

� In case of multi-band cell, should take into account the difference of propagation between GSM and DCS and the difference of BTS transmission power in the two bands

� Added to cause 11 threshold RXLEV_DL_ZONE








1 � 9 � 90

� PING_PONG_MARGIN(0,call_ref)

� Penalty PING_PONG_HCP put on cause 13 if

� The immediately preceding zone in which the call has been is the inner zone of the serving cell

� And the last handover was not external intracell

� And T_HCP is still running

� PING_PONG_MARGIN(0,call_ref) = 0

� If the call was not previously in the serving inner zone

� Or T_HCP has expired



Conce

ntric cell

In n e r z o n e

Outer zone






1 � 9 � 91

� neighbour_RXLEV(0,n)

� Concentric cells are designed to create an INNER zone

� protected from external interferers

� and creating no interferences on other cells

� … to be able to face more aggressive frequency reuse in INNER zone TRXs

� neighbour_RXLEV(0,n) tuning enables to avoid handovers if the MS position will lead to interferences

� the condition is checked towards all neighbor cells belonging to the same layer and band as the serving cell



Concentric cellOuter zone

?

Inner zoneinterferer 1

Inner zoneinterferer 2Inner zone






1 � 9 � 92

� EN_CAUSE_13

� Load balance between inner and outer zones may be allowed by setting EN_LOAD_BALANCE = ENABLE

� If EN_LOAD_BALANCE = ENABLE

� If INNER zone is less loaded than OUTER,EN_CAUSE_13 = ENABLE

� If INNER zone is more loaded than OUTER,EN_CAUSE_13 = DISABLE

� If EN_LOAD_BALANCE = DISABLE

� EN_CAUSE_13 = ENABLE








1 � 9 � 93

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






1 � 9 � 94

� Incoming intercell handovers towards a concentric cell

� In case an MS makes an incoming handover towards a concentric cell (due to outer PBGT measurements,etc.), a TCH may be allocated

� either in the INNER or in the OUTER zone, as for call setup

� depending on radio conditions

� In case of a multi-band cell, if the MS is not multi-band, it will always be sent to the OUTER zone


Incoming Intercell Handovers towards Concentric Cell


Inner zone

Cell

??






1 � 9 � 95

� Use part of Handover cause 13 algorithm on each potential target

� IF Cell(n) is external

� The MS is directed to the OUTER zone of (n)

� ELSE (cell(n) is internal)

� IF

AV_RXLEV_NCELL(n) > RXLEV_DL_ZONE + ZONE_HO_HYST_DL ++ (BS_TXPWR - BS_TXPWR_MAX_INNER)

and EN_BETTER_ZONE_HO = ENABLE

� The MS is directed towards the INNER zone

� ELSE

� The MS is directed towards the OUTER zone


Incoming Intercell Handovers towards Concentric Cell [cont.]






1 � 9 � 96









1 � 9 � 97

End of ModuleAnnexes

@@COURSENAME - Page 2All Rights Reserved © Alcatel-Lucent @@YEAR

All rights reserved © Alcatel-Lucent @@YEARPassing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent

3FL10491ADAAWBZZA_02

Documents

Transcript of 3FL10491ADAAWBZZA_02