Network Optimization & Tuning:

BR 9.0
Feature impacts analysis FRS 92893
Repeated FACH (R-FACCH)

Version 1.0
Document status: IUS

Author: Krystian Majchrowicz

Date:

21.03.2007

SN SDC NA B1

Tel.: +48 71 777-74441

E-mail: [email protected]

This page is intentionally left blank

Table of contents
TABLE OF CONTENTS ............................................................................................. 3
1

HISTORY ..................................................................................................... 6

LITERATURE REFERENCES ..................................................................... 7

INTRODUCTION .......................................................................................... 8

3.1

Repeated FACCH (R-FACCH) ........................................................................................................ 9

3.2

Prerequisites for applicability of R-FACCH ................................................................................... 9

3.3

When the R-FACCH applies to an on-going call .......................................................................... 10

NETWORK INTRODUCTION AND PARAMETERIZATION ASPECTS .... 11

CONTEXT OF APPLICATION AND EXPECTED BENEFIT ...................... 13

5.1

Application context .......................................................................................................................... 13

5.2

Expected influence of R-FACCH on the network performance .................................................. 13

5.3

Possible side effect of the introduction of R-FACCH ................................................................... 17

5.4

Cell context proposals for analysis of R-FACCH effects.............................................................. 17

RESULTS OF SIMULATIONS OR COLLECTED FROM FIELD ............... 18

7
VERIFICATION OF THE NETWORK IMPROVEMENT AFTER FEATURE
INTRODUCTION ...................................................................................................... 19
8

EVALUATION OF THE FEATURE IMPACT WITH SAG TOOLS ............. 20

8.1

Feature impact on AnatomN........................................................................................................... 20

8.2

Feature impact on Radio Network Analyser (RNA)..................................................................... 20

8.3

Feature impact on Siemens PM Counters...................................................................................... 21

INDEX OF FIGURES

ABBREVIATIONS
ACCH

Associated Control Channel

AFS

AMR Fullrate Speech

AHS

AMR Halfrate Speech

AMR

Adaptive Multi Rate

ASS CMD

Assignment Command

ASS CMP

Assignment Complete

BTS

Base Transceiver Station

CDR

Call Drop Rate

CGI

Cell Global Identifier

CONACK

Connection Acknowledgement

DL

Downlink

DM

Disconnect Mode

EFL

Effective Fractional Load

EFR

Enhanced Full Rate

FACCH

Fast Associated Control Channel

FR

Full Rate

GMSK

Gaussian Modulation Shift Keying

HO

Handover

HOAF

Handover Access Failure

HO CMD

Handover Command

HO CMP

Handover Complete

HSCSD

High Speed Circuit Switch Data

HR

Half Rate

Information frame

LAPDm

Link Access Protocol on Dm channel

MS

Mobile Station

NOT

Network Optimization and Tuning

PHYS INFO

Physical Information

RLF

Radio Link Failure

RR

Received Ready

SABM

Set Asynchronous Balance Mode

SACCH

Slow Associated Control Channel

TA

Timing Advance

UA

Unnumbered Acknowledged

UI

Unnumbered Information

UL

Uplink

History

Version

Date

Chapter

Changes / Reasons

0.1

18.12.2006

DRAFT_AFI

0.2

11.01.2007

Correction after first review phase

1.0

21.03.2007

Set to IUS

Literature references
1. [AEK92893] FRS Repeated FACCH and Temporary Overpower on FACCH and
SACCH for Reduced Call Drop Rate, Dr. Kolio Ivanov, 07.08.2006,
2. BR 9.0 Initial Enabling (Siemens internal)
Temporary Overpower & Repeated FACCH, Eckardt Bertermann, 13.11.2006
3. Database Parameter Description
4. PM: SBS counter
5. [CR2745] Maximum Capacity Booster

Introduction

Originally in GSM the robustness of the signalling ACCH has been designed to match
with the error protection schemes of the standard GSM FR and HR speech TCH
(TCH/FS, TCH/HS). The robustness of the GSM TCH has been substantially
increased by the introduction of Adaptive Multi Rate (AMR) speech codecs capable
of adapting the relative amount of speech and coding to the prevailing radio
conditions. The most robust AMR codec modes, e.g. TCH/AFS4.75 and
TCH/AFS5.90 provide sufficient voice quality even at very low C/I levels down to 2
dB. The robustness of ACCH, however, has not been improved, yet.

Figure 1 FER vs. C/I for different coding mode for TU3 scenario (source: 3GPP TSG
GERAN #19)

The analysis of the call drop statistics in real networks planned in tight reuse and
operated at medium fractional load also shows that the vulnerability of ACCH
especially downlink is currently the limiting factor for the network capacity. In uplink
direction Interference Cancellation (UIC) has been introduced in BR8.0, capable of
improving also the performance for signalling channels, i.e. no critical degradation of
ACCH performance is expected in UL. Analysis of trace data and performance
counters have shown that most of the call drops occur during the HO procedure. This
is a strong indication that especially the HO messages sent via FACCH are causing
the strong increase in call drop rate. Therefore in BR 9.0 two approaches to address
the issue with ACCH on downlink has been implemented:

1. By improving the error protection schemes for FACCH implying changes in the
3GPP standard.
2. By improving the C/I on DL ACCH using a higher transmit power on FACCH
and SACCH bursts.
The feature Repeated FACCH was developed in order to improve error protection
for FACCH by transmitting redundant number of FACCH block. The second approach
to improve performance of signaling channel is Temporary OverPower (TOP) which
is the feature described in dedicated NOT document.
3.1

Repeated FACCH (R-FACCH)

The feature Repeated FACCH foresees, under specific defined conditions, to apply
transmit redundancy by sending a FACCH block two times, the second (repeated)
block being sent immediately after the first one.
Which mechanism triggers this re-transmission, is context-dependent, e.g.

For layer 2 I-frames (e.g. HO CMD, ASS CMD etc.), the usual trigger is
the expiry of T200.

For layer 2 UI-frames (containing the PHYS INFO message), the trigger is
the expiry of T3105.

For layer 2 UA-frames the trigger is the repeated reception of an SABM.

The gain of this repetition mechanism on the MS side depends on the capability of
the MS to exploit this transmit redundancy in the best possible way.
In more detail, MSs compliant with 3GPP Rel-6, are capable of performing a joint
decoding (aka chase combining) of the two consecutively received FACCH blocks,
while legacy MSs can only treat the two received FACCH blocks as two separately
received blocks.
When the BSS has decided to activate R-FACCH for a particular FACCH block, the
repeated FACCH block is sent in such a way that, if the first burst of the DL FACCH
block is sent in TDMA frame M, the first burst of the repeated downlink FACCH block
is sent in TDMA frame M+8 (or M+9, if FACCH blocks are separated by a SACCH
frame or an idle frame).

3.2

Prerequisites for applicability of R-FACCH

Repeated FACCH is implemented on the BTS+ hardware platform only. The feature
is applicable for LAPDm frames sent in DL for TCH/F and TCH/H for GMSK
modulated speech services only (not implemented for HSCSD). R-FACCH is not
applied, if the TCH is in signaling only mode.

3.3

When the R-FACCH applies to an on-going call

The R-FACCH functionality is activated for a speech call in progress using the
speech codec type for which R-FACCH has been enabled in the cell if a repetition of
the first FACCH block is required (provided that for this LAPDm frame type R-FACCH
is applicable).
It is possible to apply R-FACCH on the following FACCH messages:

LAPDm command frames, including

o

I-frames (Information frames, sent in acknowledged mode (using T200))

carrying e.g. CONNECT, ALERT, CONACK messages during the call setup
phase, ASSIGNMENT COMMAND, HANDOVER COMMAND during HO
phase, CHANNEL RELEASE, RELEASE COMPLETE during call release
phase.

UI-frames (Unnumbered Information frames, unacknowledged mode)

sent during the handover phase (PHYSICAL INFORMATION).

LAPDm response frames, including

o

UA-frames (Unnumbered Ack, used to acknowledge an SABM frame)

RR-frames (Receive ready frames are transmitted, when no information is to

be transmitted on higher layers)

DM-frames (frames that indicate the disconnection of an established layer 2

connection)

R-FACCH functionality is immediately deactivated as soon as the transmission of the

repeated FACCH block has been completed.

Network introduction and parameterization aspects

R-FACCH lab tests with a BTS test load and legacy mobiles revealed that R-FACCH
applied on I-frames carrying ASS CMD and HO CMD has no impact on any of the
tested MS. However, some MSs seem to have problems with repeated I-frames
carrying e.g. the CONNECT message and/or UA-frames.
In order to avoid potential problems with legacy MSs, specific enabling options were
implemented that allow, for MS with R-ACCH_CAP=0, a restriction of the R-FACCH
application to specific LAPDm command frame types only.
The following R-FACCH enabling parameters were implemented in BR9.0:

enableRFacchOnCmdFrames (ERFACCHCMD), enables R-FACCH for MSs

with R-ACCH_CAP=0 (or legacy MSs) on I-frames containing ASS CMD and
HO CMD only, separately per speech codec type.

applyRFacchOnAnyCmdFrame (RFACCHCMD), enables (per boolean flag) RFACCH for MSs with R-ACCH_CAP=0 for all LAPD command frames.

enableRFacchOnLapdmFrame (ERFACCHANY), enables R-FACCH on any

LAPDm command and response frame for MS with R-ACCH_CAP=1,
separately per speech codec type.

For R-FACCH, the operator may use the possibility to enable R-FACCH separately
for specific codec types for a careful and step-wise activation of the feature for
modern MS types first, as the speech versions supported by the MS quasi reflect the
MS generation:

AMR supported: new generation MS

EFR supported: medium generation MS

Only standard FR/HR supported: old generation MS

In other words, in a network that supports both AMR and non-AMR speech services,
it can be assumed that MSs are served by a non-AMR codec only if they do not
support AMR and that they can therefore be regarded as an MS of an older
generation.
According to 3GPP TS24.008 V7.4.0 the R-FACCH capability of the MS shall be
signaled to the network at call setup via the 1-bit flag Repeated ACCH Capability (RACCH_CAP) which is part of the Classmark 3 information element sent in the
CLASSMARK CHANGE message.
If this bit is set to 1 (R-ACCH_CAP=1), this indicates the MSs capability to support
both R-FACCH and R-SACCH (planned for BR10). Only for those MSs with R-

ACCH_CAP=1, R-FACCH is applied on LAPDm response frames (UA-, RR- and DMframes).
If this bit is set to 0 (R_ACCH_CAP=0), this indicates the MSs capability to support
R-FACCH on LAPDm command frames only.
Unfortunately, with the standards specification, the BSS cannot distinguish between
Rel-6 MSs with R-ACCH_CAP=0 and legacy MSs. The difference between Rel-6
MSs with R-ACCH_CAP=0 and legacy MSs is that the Rel-6 MS is capable to
perform joint decoding (chase combining) of repeated FACCH blocks, while legacy
mobile MSs treat these two identical FACCH blocks as two separately received
blocks
Due to the R-FACCH problems experienced with legacy MS (that could result in
additional call drops) the operator should enable R-FACCH in the following
sequence, always observing the CDR for a possible systematic increase:
1. ERFACCHALPDMF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS|TCH_HS|TCH_FS)
2. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS), ARFACCHACMDF=FALSE
3. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS), ARFACCHACMDF=TRUE
4. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS),
ARFACCHACMDF=FALSE
5. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS),
ARFACCHACMDF=TRUE
6. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS|TCH_FS|TCH_HS),
ARFACCHACMDF=FALSE
7. ERFACCHCMDF=ENABLE(TCH_AFS|TCH_AHS|TCH_EFS|TCH_FS|TCH_HS),
ARFACCHACMDF=TRUE
Apart of the enabling options speaking about parameterization it is worth to
remember that R-FACCH feature impacts the timer on BTS.
For layer 2 frames sent in acknowledged mode, the timer T200 is started to observe
the reception of the layer 2 acknowledgement of the transmitted layer 2 frame. If RFACCH is applied for layer 2 frames sent in acknowledged mode, the BTS starts
timer T200 only for the repeated FACCH block (i.e. T200 is not started for the first
FACCH block but for the second one).
If the BTS transmits the PHYS INFO message, it starts T3105 to observe the receipt
of the SABM message. In case of activated R-FACCH, the value of T3105 is
increased by 8 or 9 TDMA frames (the latter corresponding to the case where the two
FACCH blocks are separated by either a SACCH frame or an idle frame).

Context of application and expected benefit

5.1

Application context

Since a significant portion of call drops is caused by lost assignment and handover
command messages the feature R-FACCH is expected to substantially reduce the
dropped call rate both in interference and coverage limited GERAN deployments.
5.2

Expected influence of R-FACCH on the network performance

The main effect of R-FACCH is an improvement of HO performances in critical

situations, which finally shall lead to a reduced call drop during HO.
On the determination of the final cause of dropping during HO, of high importance is
the timers configuration defined by operator for its network.
Assuming a properly configured network the area of expected improvement can be
identified analyzing feature employment scenarios during handover. Therefore the
figure below illustrates message flow for intercell HO procedure. Marked in yellow
there are these messages that are impacted by R-FACCH feature.

Figure 2 Message flow for intercell HO.

The first message in HO procedure which is impacted by R-FACCH is HO CMD. This
message is sent in acknowledge mode and therefore MS should send Received

Ready LAPDm response frame as acknowledgement. 1 In BTS timer T200 waits to

receive the acknowledgement and if it expires it retransmits HO CMD. After N200
retransmissions BTS sends ERROR INDICATION and connection is regarded as
dropped.
With R-FACCH feature in case of retransmission two identical FACCH block are sent
one after another what increases probability that FACCH block will be correctly
decoded. This causes that the number of call drops due to T200 expiry will decrease.
The second message for which the R-FACCH will increase the probability of correct
decoding is Physical Information. This message is sent by BTS and timer T3105 is
started. T3105 runs as long as BTS receives SABM message or it expires. After
T3105 expiry BTS retransmits PHYS INFO. After NY1 retransmissions BTS sends a
CONNECTION FAILURE indication with cause 'Handover access failure' to the BSC
and the new allocated channels are released.
In order to avoid the transmission of the CONN FAIL indication while the MS falls
back to the old channel due to unsuccessful access to the target cell (thus an
unjustified registration of a 'call drop') following inequality must be satisfied:
NY1*T3105 >= 2 sec.
As R-FACCH improves performance of downlink FACCH in case that it was activated
on any LAPDm command frames (ARFACCHACMDF = TRUE) the number of call
drops due to HOAF should decrease.
The last message which probability of correct decoding is increased by R- FACCH is
Unnumbered Acknowledgement (UA). UA frames are only sent as a response to
received command frames SABM. If MS does not receive UA as response to SABM
it retransmits this command frame. The time between two retransmissions is 32
TDMA frames (T200 setting on the MS side) in case of FR speech TCH (40 TDMA
frames in case of HR speech TCH) and the total number of retransmissions (N200 on
the MS side for SABM) is restricted to 5. If the UA-frame is correctly received the MS
will send on the UL FACCH of the new channel the ASS CMP or HO CMP message
concluding a successful HO procedure. If the MS was not able to correctly decode
the UA-frame (after it has been retransmitted 5 times as described above) the MS
returns to the old cell (handover fallback).
Assuming that R-FACCH is active on any LAPDm frames (ERFACCHALPDMF =
ENABLE) the better FACCH performance on UA frames will decrease number of
unsuccessful HO with reversion to old cell (HO fallback) should decrease.
It can happen that HO fallback will be unsuccessful (eg. SABM to the old cell does
not get through). In such a case BSC receives neither HO CMP nor HO FAILURE, T8
1

In practice - whether the MS acknowledges a single I-frame on the old channel (by RR-response) before it switches over to the
new channel depends on the mobile type (i.e. some mobiles do send the RR, others do not). This means that it can happen that,
during an ongoing channel change procedure (HO, TCH assignment etc.) the I-frame that contains channel change message
(e.g. HO CMD) is continuously repeated by the BTS due to missing layer-2 acknowledgement on the old channel. This 'T200context' is terminated:
a) after successful access to the new channel: by the release of the old channel (RF CHANNEL RELEASE received at the BTS), or
b) by the receipt of a new SABM from the MS on return to the old channel after unsuccessful access to the target channel (this
SABM initializes the T200 context and flushes the previous timer history).

in BSC expires and connection is released. For this reason R-FACCH on UA frames
will decrease the number of Unsuccessful Internal Handovers Intercell with Loss of
MS.
As R- FACCH is also used in intracell HO this procedure must be also analyzed in
order to find expected benefit from R-FACCH. The following picture presents
message flow for intracell HO. Marked in yellow there are these messages that are
impacted by R-FACCH feature.

Figure 3 Message flow for intracell HO

In case of intracell HO the first message which is impacted by R-FACCH is
ASSIGNMENT COMMAND. It is Information frame (one of the LAPDm command
frame) which is send in acknowledgement mode. The supervision timer (which waits
for reception confirmation) is T200. Therefore similar to intercell HO R-FAACH on
ASS CMD message will decrease the number of call drops due to T200.
The next message affected by the feature is UA. If MS does not receive UA it
retransmits this SABM frame. The number of retransmissions (N200 on the MS side
for SABM) is restricted to 5. If the MS was not able to correctly decode the UA-frame
(after 5 retransmissions) the MS returns to the old channel.
If R-FACCH is active on UA frames the number of unsuccessful HO with reversion to
old channel (HO fallback) should decrease.

It can happen that HO fallback will be unsuccessful (eg. SABM to the old channel
does not get through). In such a case BSC receives neither ASS CMP nor ASS
FAILURE, T10 in BSC expires and connection is released. For this reason R-FACCH
on UA frames will decrease the number of Unsuccessful Internal Handovers Intracell
with Loss of MS.
As ASS CMD is also in use during TCH assignment procedure, feature R-FACCH
impacts SDCCH drop statistics. In order to better understand it, message flow for
assignment procedure should be analyzed. TCH assignment is the procedure when
after immediate assignment (connection on SDCCH is established) connection is
switched over from SDCCH to TCH.

Figure 4 Message flow for TCH assignment procedure

In case of TCH assignment R-FACCH is used on ASS CMD message the probability
that SDCCH drop due to T200 expiry is decreased. It also decreases the number of
assignment failure due to T10 expiry (radio interface message failure). For R-FACCH
activation on UA frames the advantage is reduced number of unsuccessful TCH
assignments with reversion to SDCCH.

R-FACCH was developed in order to reduce the number of call drops in the network.
This is soft capacity feature as reduced CDR (as benefit from R-FACCH) allows us to
go to the higher EFL. Thus the benefit in CDR figure can be easily transformed into
the capacity.

5.3

Possible side effect of the introduction of R-FACCH

As described in chapter 1 RFACCH works in this way that in need of retransmission

of DL FACCH block BTS sends two identical FACCH blocks immediately (instead of
the one). This improves FACCH performance but it also increases the number of
redundant signaling messages. As during the intercell HO these FACCH blocks are
sent at maximum power R-FACCH can slightly increase interferences. However
feature impact on interference is so low that it can be neglected (specially comparing
to benefit in call drop statistics).
5.4

Cell context proposals for analysis of R-FACCH effects

The effects of the introduction of R-FACCH can be verified in any cluster of cells as
feature gives the benefit both in noise and interference limited scenarios.

Results of simulations or collected from field

According to link level simulation results the expected gain for Downlink Repeated
FACCH functionality is about 4dB for new MS (i.e. compliant with Rel-6), capable
of performing a joint decoding (chase combining), and about 2 dB for legacy MS
(due to fast FACCH repetition). Apparently the benefit strongly depends on the
penetration rate of Rel-6 compliant MS.
The presented here benefit refers to C/I conditions which can now decrease about
4 dB or 2 dB correspondingly to guarantee stable connection.

7
Verification
introduction

of

the

network

improvement

after

feature

In order to estimate the improvement provided by R-FACCH it is suggested to

observe counters and KPI related to call drops (and call drops in relation to traffic
load) before and after feature activation. It is expected that these counters should
generally indicate a decrease of the call drop figures.
Applying the R-FACCH feature shall result in the following changes (towards network
without R_FACCH) of the certain KPIs (for definitions of specific KPIs refer to chapter
8):

Drops due to T200 per Erlh will decrease;

Drops due to HOAF per Erlh will decrease;

Intercell HO Drops (T8 expiries) will decrease;

Intracell HO Drops (T10 expiries) will decrease;

Call drop rate, TCH drop rate, TCH Drop Erlh will decrease;

HO failure rate will decrease;

TCH Assignment failure rate will decrease;

SDCCH drops due to T200 per Erlh will decrease;

FACCH repetition rate should increase.

Additionally the feature can be verified by History on Dropped Call Traces as this
functionality provides additional information about the status of the connection which
was dropped as: UL and DL RxLev, UL and DL RxQual, TA, CGI of the target cell (in
case of call drop during HO procedure).

Evaluation of the feature impact with SAG tools

8.1

Feature impact on AnatomN

The idea of this document is to present how to measure expected benefit coming
from implementation of R-FACCH. In order to do this the results of PM counters
before feature activation have to be collected and then compared to the results from
the period after R-FACCH activation. This can be done in AnatomN with the usage of
attached predefined report which can be simply saved and imported in AnatomN (this
report can be updated with new BR 9.0 counters when AnatomN v2.1 with BR 9.0
counters is available).

R-FACCH feature
verfication.arp

Figure 5 AnatomN predefined report presenting KPIs which should be observed in

order to verify benefit from R-FACCH activation.
8.2

Feature impact on Radio Network Analyser (RNA)

Radio Network Analyzer provides the History on Dropped Call functionality which
allows tracing of the number of calls which were dropped with cause of drop and
additional information as RxQual, RxLev, TA and CGI of the target cell (if drop

occurred during handover). Therefore this tool can be used as the crosscheck option
for the analysis performed in post processing offline PM tool (like AnatomN).
8.3

Feature impact on Siemens PM Counters

The implementation of R-FACCH will have significant impact on the network

performance. This impact will obviously influence the results of Performance
Measurement counters in Siemens SBS. Here below listed all counters which results
will change after introducing R-FACCH which stay behind the formulas of the KPIs
included in AnatomN report enclosed in chapter 8.1.
FACCHSUP - FACCH Supervision - this is new BR 9.0 measurement which provides
the number of transmitted I (ASSHOCMD), UI (PHYS INFO) and UA frames as well
as it gives the number of transmitted FACCH blocks utilized to send these frames (I,
UA and UI) over the radio interface. It differentiates for 5 codec types: FR, HR, EFR,
AFS and AHS thus all together there are 10 new subcounters. Based on them KPI
FACCH Repetition Rate can be calculated as:
FACCH Repetition Rate = 1 - FACCHSUP(k)/ FACCHSUP(k+5), k=1,.5
where k represents subcounter number dedicated for a specific codec type
KPI interpretation:
Let assume that there were 8 different HO CMD received by BTS which were
segmented into 8 FACCH blocks. For one FACCH block retransmission was needed
as T200 expired. This retransmitted block was sent twice due to R-FACCH
functionality. All together 10 FACCH blocks were sent on the air interface while only 8
HO CMD were received by the BTS. In such a case FACCH Repetition Rate = 2/10
what means that 10 FACCH blocks including 2 retransmissions.
As R-FACCH sends two identical FACCH blocks twice (when retransmission is
needed) it is expected that after feature activation KPI FACCH Repetition Rate will
considerable increase.
Impact on call drop statistics
NRFLTCH [1,10] Number of lost TCH connection - this measurement determines
the total number of lost connections (while using TCH/F or TCH/H) due to T200
expiry. Based on this counter, KPI which gives the relation between drops due to
T200 expiry and carried traffic can be calculated.
Drops_T200_Erlh = NRFLTCH[1,10] / MEBUSTCH[1..4]
where MEBUSTCH = Mean Number of Busy TCHs counters;
With enabled R-FACCH it is expected that the value of this KPI will significantly
decrease.

NRFLTCH [6,15] Number of lost TCH connection - this measurement determines the

total number of lost connections (while using TCH/F or TCH/H) due to handover
access failure (T3105 expires NY+1 times and MS does not succeed to return to the
old cell with HO FAIL).
Based on this counter, KPI which gives the relation between HOAF drops and carried
traffic can be calculated.
Drops_T200_Erlh = NRFLTCH[6, 15] / MEBUSTCH[1..4]
With activated R-FACCH it is expected that the value of this KPI will significantly
decrease.
NRFLTCH [9,18] - Number of lost TCH connection - this measurement determines the

total number of lost connections (while using TCH/F or TCH/H) due to unspecified
cause. It is triggered by the expiry of the timer BSCT8 in the context of an MSCcontrolled intercell or intracell TCH-TCH handover or the expiry of the timer
BSCT3121 in the context of an outgoing 3G-MSC-controlled 2G-3G handover.
Based on this counter, KPI which gives the relation between these drops and carried
traffic can be calculated.
Drops_Other_Erlh = NRFLTCH [9, 18] / MEBUSTCH[1..4]
With activated R-FACCH it is expected that the value of this KPI will significantly
decrease.
UNIHIALC - Unsuccessful Internal Handovers Intracell with Loss of MS - this

measurement determines the number of intracell handover failures where connection

with the MS was lost and T8 expired.
From this counter the rate between intercell HO drops and the traffic can be
estimnated.
HO_Drops_Erlh = UNIHIALC / MEBUSTCH[1..4]
With enabled R-FACCH it is expected that the value of this KPI will significantly
decrease.
UNIHIRLC - Unsuccessful Internal Handovers Intercell with Loss of MS - this
measurement determines the number of intercell handover failures where connection
with the MS was lost and BSC timer T10 expired.
From this counter the rate between intercell HO drops and the traffic can be
estimnated.
HO_Drops_Erlh = UNIHIRLC / MEBUSTCH[1..4]
With enabled R-FACCH it is expected that the value of this KPI will significantly
decrease.
The counters presented above are included in the call drop statics as: CDR, TCH
Drop Rate and TCH Drop Erlh. Since these counters are impacted by R_FACCH

feature these call drop statiscs (mentioned above) will decrease together with the
counter values.
Impact on handover statistics
When R-FACCH is active it is expected that following counters related to
unsuccessful HO procedure will reduce their values:
UNINHOIA [1..14] - Unsuccessful Internal Handovers Intracell - this measurement

provides the total number of unsuccessful intracell handovers with reversion to old
channel.
UNINHOIE [1..11] - Unsuccessful Internal Handovers Intercell - this measurement
provides the number of unsuccessful intra-BSC-HOs per cell with reversion to old
cell.
NRUNINHD [1..10*n] - Unsuccessful Outgoing Inter-BSC Handovers - this measurement
provides the number of unsuccessful inter-BSC-HOs with reversion to old cell. (n
represents number of neighbour relation per cell)
UNOISHDO [1 .. 10*n] - Number of Unsuccessful Outgoing Intersystem Handovers - this
measurement provides the number of unsuccessful handovers from the observed GSM cell
to a neighbour UMTS (cell controlled by a different system) with reversion to old cell. (n
represents number of neighbour relation per cell)

Based on above listed counters HO Failure Rate can be calculated as relation

between unsuccessful HOs (intracell, intercell intra BSC, intercell inter BSC,
intersystem) to all attempted HO.
HO Failure Rate =( UNINHOIA [1..14] + UNINHOIE [1..11] + NRUNINHD [1..10*n] +
UNOISHDO [1 .. 10*n])/ (ATINHIAC [1..14] + ATINHIRC [1..11]+ ATINBHDO
[1..10*n] + ATOISHDO [1 .. 10*n])
Repeated FACCH functionality will reduce the value of this KPI.
Impact on assignment statistics:
TASSFAIL [6,7,11,12] - (number of times an assignment attempt of a TCH or SDCCH

failed due to radio interface message failure or due to radio interface failure reversion to old channel) should decrease.
Based on this counter TCH Assignment Failure Rate can be calculated:
TCH Assignment Failure Rate = TASSFAIL [6,7,11,12] / TASSATT [1..3]
Impact on SDCCH drop statistics:
NRFLSDCC [1] Number of lost SDCCH connection - this measurement determines
the total number of lost connections (while using SDCCH) due to T200 expiry. Based
on this counter, KPI which gives the relation between drops due to T200 expiry and
carried traffic on SDCCH can be calculated.

SDCCH_Drops_T200_Erlh = NRFLSDCC [1] / MBUSYSDC

where MBUSYSDC = Mean Number of Busy SDCCHs;

With enabled R-FACCH it is expected that the value of this KPI will significantly
decrease.